Reading C, C++, CUDA and Rust

CUDA: one thread per element

A GPU runs thousands of threads at once, all running the same function, a kernel, on different elements. Threads are grouped into blocks, and each thread works out which element is its own from three built-in numbers:

__global__ void scale(const float *x, float *out, float a, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) {
        out[i] = a * x[i];
    }
}

// on the CPU: enough blocks of 256 threads to cover n elements
int blocks = (n + 255) / 256;
scale<<<blocks, 256>>>(x, out, 2.0f, n);

__global__ marks a kernel; <<<blocks, threads>>> launches it. Block 2, thread 5, with 256 threads per block, handles element 2 * 256 + 5. The number of blocks is rounded up so every element gets a thread, which means the last block usually has spare threads past the end. if (i < n) stops those from writing past the array, a write that C wouldn't catch for you.

The other thing to look for is copying. A kernel can only use data that's already in the GPU's memory, and moving data between the computer's memory and the GPU (cudaMemcpy in CUDA) is slow next to the arithmetic itself. That's why PyTorch keeps tensors on the GPU from one operation to the next, and why a stray .item() or .cpu() inside a training loop, which forces a copy back every step, can make the whole loop crawl.

n, threads = 1000, 256
blocks = (n + threads - 1) // threads
print(blocks, blocks * threads - n)

Rust: types after names, and ownership

Rust looks like a mix of C and Python, with types after names (count: usize) and let (or let mut for a value that changes). Its unusual idea is ownership: each value has one owner, and passing it to a function moves it unless you lend it with a reference, &value to read or &mut value to change. That's how Rust frees memory safely without a garbage collector, and why you'll see so many &s.

Rust's Option and Result

Errors in Rust are values, returned like any other result:

fn parse_port(text: &str) -> Result<u16, String> {
    let n: u32 = text.trim().parse().map_err(|_| format!("not a number: {text}"))?;
    if n == 0 || n > 65535 {
        return Err(format!("out of range: {n}"));
    }
    Ok(n as u16)
}

Rust has no exceptions and no None that sneaks in. A value that may be missing is an Option (Some(x) or None), and a call that may fail returns a Result (Ok(value) or Err(error)). The ? at the end of a line means "if this is an error, return it now", much like letting a Python exception propagate. .unwrap() means "I'm sure it's fine, crash if not": worth a second look in review.

for (int i = 0; i <= n; i++) total += prices[i];

def total_price(prices):
    n = len(prices)
    total = 0
    for i in range(n + 1):
        total += prices[i]
    return total


print(total_price([189, 12, 79]))

A strategy for reading unfamiliar code

You don't read a C++ file from the top. Find the function you care about, say the operator your model calls, and read its signature first: what goes in, what comes out, what may fail. Then find the loop or the kernel launch where the real work happens and translate just that part in your head to Python. Skip includes, macros and error-handling boilerplate on the first pass.

Keep a short list of questions as you go. Where's the length checked? Who frees this memory, or who owns this value in Rust? What happens on the error path? Is the work parallel, and if so, what does each thread own? Those questions find most real bugs and most performance surprises.

And use the tools: GitHub's code search, "go to definition" in an editor, and a model asked to explain one function at a time, checked against the code itself rather than trusted.