howcomputer

yeah, I tried prefetching like this: https://github.com/jvns/howcomputer/blob/master/bytesum_pref... (using MAP_POPULATE instead of hugepages) and got a slight slowdown

Interesting investigation! I had an experiment with getting the Rust compiler to vectorise things itself, and it seems LLVM does a pretty good job automatically, e.g. on my computer (x86-64), running `rustc -O bytesum.rs` optimises the core of the addition: fn inner(x: &[u8]) -> u8 { let mut s = 0; for b in x.iter() { s += *b; } s } to .LBB0_6: movdqa %xmm1, %xmm2 movdqa %xmm0, %xmm3 movdqu -16(%rsi), %xmm0 movdqu (%rsi), %xmm1 paddb %xmm3, %xmm0 paddb %xmm2, %xmm1 addq $32, %rsi addq $-32, %rdi jne .LBB0_6 I can convince clang to automatically vectorize the inner loop in [1] to equivalent code (by passing -O3), but I can't seem to get GCC to do anything but a byte-by-byte tranversal. [1]: https://github.com/jvns/howcomputer/blob/master/bytesum.c

I like the "free" style of the article. Here is another conclusion: In my professional life I have heard many, many excuses in the name of performance. "We don't need the third normal form, after all, normalized databases are less performant, because of the joins". Optimizing for performance should not mean to make it just as fast as it could possibly run, but to make it just fast enough. Julia's article shows a good example for this. Of course, the goal appears to generate a feeling of what tends to make a program fast and slow and get a feeling for how slow it will be or how fast it can get; yet I'd like to point out that this... https://github.com/jvns/howcomputer/blob/master/bytesum_intr... ... might be 0.1 Seconds faster than the original code when started as "already loaded into ram" which she claims runs at 0.6 seconds. Yet this la