CPU

Nota bene : This content was generated by AI. I am working on this page to provide personal content of better quality.

This page covers the key elements of CPU architecture for quantitative finance: data ingestion, feature engineering, backtesting, classical models (trees, regression, Monte Carlo), and ML pipeline orchestration. Hardware details may differ between Intel, AMD, and ARM (Apple Silicon). The focus is on x86-64 (Intel/AMD), the most common architecture in trading and quant research environments.

Structure

x86-64 CPU
│
├── Compute Core
│   ├── Physical Cores
│   ├── Logical Threads (SMT / Hyper-Threading)
│   ├── ALU / FPU
│   ├── SIMD Units (SSE, AVX, AVX-512)
│   ├── Branch Predictor
│   └── Out-of-Order Execution Engine
│
├── Cache Hierarchy
│   ├── L1 Instruction Cache
│   ├── L1 Data Cache
│   ├── L2 Cache (per core)
│   └── L3 Cache / LLC (shared)
│
├── Memory Subsystem
│   ├── RAM (DDR4 / DDR5)
│   ├── Memory Controllers
│   ├── Memory Channels
│   └── NUMA Nodes
│
├── I/O and Interconnect
│   ├── PCIe Lanes
│   ├── QPI / UPI / Infinity Fabric
│   └── Chipset / I/O Hub
│
├── Execution Model
│   ├── Processes
│   ├── OS Threads
│   ├── Vectorization (SIMD)
│   └── Multi-core Parallelism
│
├── Multi-Socket
│   └── NUMA Topology
│
└── Software Stack
    ├── OS Scheduler
    ├── BLAS (OpenBLAS, MKL)
    ├── NumPy / Pandas
    ├── Polars
    ├── multiprocessing / threading
    ├── joblib
    └── scikit-learn / XGBoost (CPU)

Compute Core

The compute core executes program instructions. Unlike the GPU (SIMT, thousands of lightweight threads), the CPU is optimized for latency and complex conditional branches — typical of business logic Python code in finance.

Physical cores and logical threads

A physical core is an independent execution unit. SMT (Simultaneous Multi-Threading, Hyper-Threading on Intel) exposes two logical threads per core, sharing execution units. In quant workloads, this mainly helps mixed I/O + compute tasks; for pure compute (NumPy, BLAS), counting physical cores is often more reliable than logical thread count.

Component	Role
ALU	Integer and scalar arithmetic operations (additions, comparisons, indexing)
FPU	Floating-point computation (prices, returns, volatility, greeks)
SIMD (AVX)	Vector processing: one instruction operates on 4–16 values in parallel (crucial for NumPy/MKL)
Branch Predictor	Anticipates conditional jumps to reduce pipeline stalls
Out-of-Order Execution	Reorders independent instructions to maximize core throughput

SIMD and vectorization

SSE, AVX, and AVX-512 instructions operate on wide registers (128, 256, or 512 bits). In practice, most scientific Python libraries (NumPy, SciPy, scikit-learn via BLAS) already exploit these instructions under the hood — which is why installing an optimized MKL or OpenBLAS build matters.

Cache Hierarchy

The cache hierarchy bridges the latency gap between CPU and RAM. In quantitative finance, non-contiguous memory access (DataFrames, joins, groupby) heavily penalizes performance.

Level	Scope	Typical latency	Quant use case
L1	Per core (I-cache + D-cache, ~32–64 KB each)	~1 ns	Short loops on contiguous arrays
L2	Per core (~256 KB – 1 MB)	~3–4 ns	Data reuse within a rolling window
L3 / LLC	Shared across cores (8–384 MB)	~10–20 ns	Data sharing between threads in the same process
RAM	Entire system	~50–100 ns	Full DataFrames, market history, covariance matrices

Best practices: prefer vectorized operations (NumPy, Polars) over Python loops; use compact dtypes (float32 vs float64) when precision allows; avoid unnecessary DataFrame copies.

Memory Subsystem

Main memory is the most critical resource for large backtests and covariance matrices.

Element	Description
RAM (DDR4/DDR5)	Main memory. Typical capacity: 32–256 GB on quant workstations. Limits in-memory dataset size.
Memory Channels	Parallel channels (dual/quad-channel). More channels = higher memory bandwidth.
NUMA	Non-Uniform Memory Access: on multi-socket systems, each CPU has local RAM. Accessing another socket's RAM is slower.

On multi-socket servers, NUMA pinning (numactl, process affinity) can significantly improve heavy parallel compute performance.

I/O and Interconnect

The CPU orchestrates exchanges with disk, network, and GPU via PCIe. In a typical quant pipeline:

Disk read → CPU (pandas/Polars) → feature engineering → GPU or CPU training
The CPU remains the bottleneck for tick ingestion, CSV/Parquet parsing, and Python business logic

QPI/UPI (Intel) or Infinity Fabric (AMD) links connect cores to each other and to the memory controller.

Execution Model

CPU parallelism in Python operates at several levels:

Concept	Description
Process	Isolated instance with its own memory. Used by `multiprocessing` to bypass the GIL.
OS Thread	System thread sharing process memory. Limited by the GIL in CPython for pure Python code.
Vectorization	Parallelism within a single instruction (SIMD). Automatically enabled by NumPy/BLAS on C/Fortran code.
Multi-core	Parallelism across cores via `multiprocessing`, `joblib`, `concurrent.futures`.

The GIL and its implications

CPython's GIL (Global Interpreter Lock) prevents parallel execution of Python bytecode across multiple cores. In practice:

NumPy/BLAS compute: GIL is released → effective multi-core parallelism
Pure Python loops: single core → use multiprocessing or rewrite in NumPy/Cython/Numba
I/O (file reads, APIs): threading is sufficient since the GIL is released during waits

Example: parallelizing a backtest

Chargement…

n_jobs=-1 uses all available cores via separate processes.

Multi-Socket and NUMA

Production servers (risk computation, massive Monte Carlo) often have 2–4 CPU sockets. Each socket has local memory:

Place workers on the same socket as their data (numactl --cpunodebind)
Avoid false sharing: two threads modifying adjacent variables in cache
For multi-threaded Polars/NumPy, limit OMP_NUM_THREADS to one socket's core count on NUMA systems

Software Stack

The CPU software stack for quantitative finance:

Layer	Role
OS Scheduler	Distributes processes/threads across cores. CPU affinity (`taskset`) can stabilize performance.
BLAS (MKL, OpenBLAS)	Vectorized linear algebra (GEMM, dot product). Underlies NumPy and scikit-learn.
NumPy / Pandas	Numerical compute and tabular manipulation. Core of most quant pipelines.
Polars	Multi-threaded DataFrames in Rust. Often faster than pandas on large volumes.
multiprocessing / joblib	Multi-core parallelism at the Python level to bypass the GIL.
scikit-learn / XGBoost (CPU)	Classical models (Random Forest, gradient boosting) efficient on CPU for tabular datasets.

Check CPU configuration

Chargement…

Console output (example)

Architecture: AMD64 Processor: Intel64 Family 6 Model 183 Logical CPUs: 32 ... openblas64__info: libraries = ['openblas64_', 'openblas64_'] ...

CPU vs GPU in quantitative finance

Workload	CPU	GPU
Data ingestion / ETL	Preferred (I/O, parsing, business logic)	Rarely useful
Tabular feature engineering	Pandas, Polars — very efficient	cuDF / RAPIDS for huge datasets
Tree models (XGBoost, LightGBM)	Excellent on CPU, datasets < a few GB	cuML if available and dataset is massive
Deep learning (LSTM, Transformers)	Too slow for training	Nearly mandatory
Monte Carlo / simulations	Parallelizable via multiprocessing	GPU for millions of independent paths
Vectorized backtesting	NumPy/Polars on CPU, often sufficient	GPU for very wide matrices (thousands of assets × years of ticks)

Key points for quantitative finance

Choose the right parallelism: threading for I/O, multiprocessing/joblib for pure Python, multi-thread BLAS for linear algebra. - Limit OMP_NUM_THREADS: if you launch 8 joblib workers and each spawns 8 BLAS threads, you oversubscribe the CPU. - Prefer Polars for large DataFrames and complex aggregations. - Profile before optimizing: cProfile, py-spy, or scalene to distinguish Python time vs C/BLAS time. - RAM: tick-by-tick history on 5000 stocks can exceed 64 GB — plan partitioning (Parquet by date/symbol) from the start. - CPU remains central: even in a GPU pipeline, ingestion, preprocessing, and orchestration run on CPU.