4 ms·
When 'percache' is higher, there will be more instructions executed between calls to pick_address_of_random_cache_line(). That means as the out-of-order proces
by mjw1007 8y ago
When 'percache' is higher, there will be more instructions executed between calls to pick_address_of_random_cache_line().
That means as the out-of-order processor "runs ahead" while waiting for the first main-memory request, it will make fewer requests to main memory before it runs out of space in its reorder buffers, and so it won't be able to overlap so many main-memory requests.
I think this is the main effect they're seeing. It would fit in with SIMD code giving better results, and it explains why the effect mostly goes away when they make each load depend on the previous calculation.
- Const-me 8y agoNo it’s not that. The CPU runs fine, the OP was screwed up by GCC optimizer. With MSVC, there’s very small difference when testing with 8GB vectors, only 8% between 1 and 16. Here’s my portable version, scalar-only, C++, and slightly more optimized: https://github.com/Const-me/MemoryAccessCosts https://github.com/Const-me/MemoryAccessCosts The results are in result-gcc.txt and result-msvc.txt in that repo. They’re from the same PC, I’m using gcc 5.4.0 running in WSL.
- mjw1007 8y agoI think those results just show that if you persuade the autovectoriser to work you'll get the same result as for manual SIMD code, as you'd expect.
- Const-me 8y agoInitially, I didn’t know the reason is automatic vectorization. I’ve found the reason and wrote the readme after that comment: https://github.com/Const-me/MemoryAccessCosts/commits/master https://github.com/Const-me/MemoryAccessCosts/commits/master