3 ms·
A whole page of benchmark results without even listing which x86 he was testing??? This varies a lot from one generation to the next and between Intel & AMD. T
by wscott 5y ago
A whole page of benchmark results without even listing which x86 he was testing??? This varies a lot from one generation to the next and between Intel & AMD.
There are a ton of tradeoffs that have to be made in the microarchitecture and in general the focus is real code and normal expected sizes rather than benchmarks. Big page multiples are common and then variable sized calls that can be totally unaligned and random sizes.
A proper study of this would test a pile of different mixes of sizes and alignments and test on a bunch of different processor generations.
And then you get results where a hand coded memcpy loop is faster in benchmarks, but in practice in a big program you might find that 'rep movs' is better because of the smaller code footprint. When you only optimize the few cases that matter.
The general rule is that the compiler and system libraries do a really good job optimizing for processors that shipped 10 years ago. So architects get to make decisions about how to help these operations. You can add a nifty feature that makes it faster (like CLZERO) but while it is good for benchmarks it will takes years after you ship before normal programs benefit. You might optimized 'rep movs' but then you find that since it was slow in the past most real system librarys don't call it.
- easytiger 5y agoHalf the benchmarks i see posted here are done on AWS instances or the authors laptop with power stepping/cstates, unisolated cores etc etc likely all enabled too, let alone basic rigour around hardware specifics. We are very much entering the age where mechanical sympathy is waning
- gpderetta 5y agoAlso the benchmark do not seem to use the same set of sizes for all benchmarks (nor use a fixed random seed) so repeatability and comparability seem questionable. I guess if you run it often enough it could still give useful numbers, but I understand the author is picking the best run. Also I don't see to be any attempt at avoiding compiler optimisations. Benchmarking is hard
- nadav256 5y agoI guess that you are referring to other projects because the benchmarks in this repo use a stable seed, turbo disabled, physical machine, both random and stable sizes, etc.
- ungamed 5y agoHavn't read the article, but c-states and p-states are different to turbo disabled.
- eternalban 5y agoWhat’s the story with the spikes for folly and your code in memcpy plots? They get chopped off and it’s not clear what number they hit. (Nice work, btw)
- astrobe_ 5y agoCPU makers add so many complicated features to let users optimize their programs that it takes too much knowledge for mere mortals to optimize their programs - That you have to rely on heuristics and measures, as it is usually and wisely advised, is a bit unsatisfying. That's sort of ironic, in a way. I used to do assembly and count cycles, but now I wouldn't dare; it's hardcore compiler and library makers stuff. It's like "don't do your own crypto (optimization)". Everyone knows why it is so, though - we cannot solve the problem by throwing more Gigahertz at it.
- cout 5y agoI have hand-written asm for use in production code, and I would do it again. I also knew exactly what cpu my code would be running on. If I were publishing the code to run on a variety of hardware, I would be very cautious. Writing your own crypto is very different; the stakes are higher if you get it wrong.
- pjmlp 5y agoIncluding the microcode version currently installed into the CPU and gone through the release notes, alongside a profile like V-Tune?
- WalterBright 5y agoA good heuristic is simply minimize the number of instructions.
- dietr1ch 5y agoIMO there's too many things to get right and no easy standard way of doing it. Is there at least a checklist? It should ideally be automated. IIRC there's some library, maybe BLAS, that at compile time computes some machine-specific constants and also refuses to do it if a few things are not right.
- CalChris 5y agoNo. The post provides an artifact so that you can test it yourself on your configuration. Knowing how it performed on this particular stepping of that particular microarchitecture won't help you on yours. Yes, your mileage may vary because your mileage always varies, even when you drive from point A to point B twice. Rant continued. I would prefer if the performance sections of papers were restricted to single paragraphs and that artifacts were required. When I'm reading papers I'm more interested in their ideas than in the third decimal place of the result on that given day on some machine I don't have. The Unix Timesharing System has no performance results. The Case For A Reduced Instruction Set Computer has no performance results. The notion that not only having results is somehow important but that providing the testing methodology and hardware configuration is also necessary is nonsense. It just lards up papers and a couple of years later the cited configuration is irrelevant. The CRAY-1 Computer System has no performance results but its section on vector processing still rings true today. It's what the RISC-V vector extension uses.
- 19528970941f 5y agoIt seems that if you're going to put in data, it should be done rigorously, otherwise, as you say, you're just, at best, distracting from the main idea.