I'm willing to bet that Apple Silicon processors have some mechanism to prevent cache pong when two cores are using values in adjacent 64-byte blocks for two reasons. Firstly, they are frequently used to emulate amd64 CPUs which have 64-byte cache lines, and exhibiting cache pong (that the emulated CPU wouldn't have) would make them very bad at it. Secondly, lots of code in the wild hardcodes the assumption that cache lines are 64 bytes long for the purpose of cache pong prevention, so making the chip perform as though this is true is necessary for it to run existing software fast.
(Sure you're supposed to query sysconf(_SC_LEVEL1_DCACHE_LINESIZE) at runtime but people certainly don't always.)
This text was written by Ivan Boldyrev. No hallucinations, no slop, no homogenization. I used AI only for brainstorming and proofreading.
I think it should become the norm to say that. I have no interest in reading AI-written posts, but in this day and age, I always need to be on the lookout for those. (On my site, I added a small "Human-written" on top of each post. I think it's better than on the bottom - start with a promise, instead of disclaiming after the text had been read)
Does your code actually guarantee that two values with 64 byte alignment are placed on the same 128 byte cache line? I suppose that depends on how Rust's Vec allocates its memory. Maybe struct AddSub should have a #[repr(align(128))]?
People keep using "x64", which is a Microsoftism, while Alpha x64 still exists. But even if we were to pretend Alpha isn't still a thing, there's riscv64, aarch64, mips64...
0x2ba22e11 | 19 hours ago
I'm willing to bet that Apple Silicon processors have some mechanism to prevent cache pong when two cores are using values in adjacent 64-byte blocks for two reasons. Firstly, they are frequently used to emulate amd64 CPUs which have 64-byte cache lines, and exhibiting cache pong (that the emulated CPU wouldn't have) would make them very bad at it. Secondly, lots of code in the wild hardcodes the assumption that cache lines are 64 bytes long for the purpose of cache pong prevention, so making the chip perform as though this is true is necessary for it to run existing software fast.
(Sure you're supposed to query
sysconf(_SC_LEVEL1_DCACHE_LINESIZE)at runtime but people certainly don't always.)radex | a day ago
This is beside the main point but:
I think it should become the norm to say that. I have no interest in reading AI-written posts, but in this day and age, I always need to be on the lookout for those. (On my site, I added a small "Human-written" on top of each post. I think it's better than on the bottom - start with a promise, instead of disclaiming after the text had been read)
[OP] monoid | a day ago
That makes sense, but I believe my non-AI Runglish is apparent from the first line. :)
radex | a day ago
honestly, no, your prose read perfectly normal to me. It didn't trigger my slop radar, but it didn't trigger my "non-native speaker" radar either ;)
[OP] monoid | a day ago
Thank you! Than there is even more motivation to move the disclaimer to the top.
luchs | a day ago
Does your code actually guarantee that two values with 64 byte alignment are placed on the same 128 byte cache line? I suppose that depends on how Rust's Vec allocates its memory. Maybe
struct AddSubshould have a#[repr(align(128))]?[OP] monoid | a day ago
There is an vector of AddSub values; if we move values by 64 bytes, it is equivalent to swapping
addandsub(with the length shorter by one, may be).johnklos | 21 hours ago
People keep using "x64", which is a Microsoftism, while Alpha x64 still exists. But even if we were to pretend Alpha isn't still a thing, there's riscv64, aarch64, mips64...
invlpg | 20 hours ago
Yes, this article should really refer to it as Intel EM64T (because they didn't reproduce the results on AMD processors). That'll be much clearer.