8 comments

[ 581 ms ] story [ 590 ms ] thread
> Don’t pass around data of size 4046-4080 bytes or 8161-8176 bytes, by value (at least not on an AMD Ryzen 3900X).

What a fascinating CPU bug. I am quite curious as to how that came to pass.

I usually use ChatGPT for such microbenchmarks (of course I design it myself and use LLM only as dumb code generator, so I don't need to remember how to measure time with nanosecond precision. I still have to add workarounds to prevent compiler over-optimizing the code). It's amazing, that when you get curious (for example, what is the fastest way to find an int in a small sorted array: using linear, binary search or branchless full scan?) you can get the answer in a couple minutes instead of spending 20-30 minutes writing the code manually.

By the way, the fastest way was branchless linear scan up to 32-64 elements, as far as I remember.

> I still have to add workarounds to prevent compiler over-optimizing the code

Yet remembering how to measure time with nanosecond precision is the burden?

> By the way, the fastest way was branchless linear scan up to 32-64 elements, as far as I remember.

The analysis presented in the article is far more interesting, qualified, and useful that what you've produced here.

There is no pass-by-value overhead. There are only implementation decisions.

Pass by value describes the semantics of a function call, not implementation. Passing a const reference in C++ is pass-by-value. If the user opts to pass "a copy" instead, nothing requires the compiler to actually copy the data. The compiler is required only to supply the actual parameter as if it was copied.

> Passing a const reference in C++ is pass-by-value.

I can cast the const away. The implementation does not hide this detail. The semantics therefore must be understood by the programmer.

You are thinking "call by value". The author probably used "pass" not "call" specifically to avoid this.
> Passing structs up to size 256 is very cheap, and uses SIMD registers.

Presumably this means for all arguments combined? If for example you pass four pointers each pointing to a 256-byte struct, you probably don’t want to pass all four structs (or even just one or two of the four?) by value instead.

I would ignore this benchmark because it’s not going to predict anything for real world code.

In real world code, your caches and the CPU’s pipeline are influenced by some complex combination of what happens at the call site and what else the program is doing. So, a particular kind of call will perform better or worse than another kind of call depending on what else is happening.

The version of this benchmark that would have had predictive power is if you compared different kinds of call across a sufficiently diverse sampling of large programs that used those calls and also did other interesting things.