3 ms·
Good point. I'm working on a project at the moment that's 100% performance oriented and it's sort of a pain to think about writing about it responsibly - i.e. k
by glangdale 8y ago
Good point. I'm working on a project at the moment that's 100% performance oriented and it's sort of a pain to think about writing about it responsibly - i.e. keeping all the intermediate steps and half-good ideas around (and bug-free, and sorta-usable) long enough to be able to do performance analysis on all the stuff.
It's hard not just to sweep all the bad ideas and half-way steps under the rug and hit the world with this "aren't I clever" looking final product (without really helping anyone learn how to get there themselves on their own projects).
- acdha 8y agoOne of the other benefits is keeping those notes around in case some assumptions change in the future and the optimization you picked is no longer viable.
- glangdale 8y agoAbsolutely, yes. Or the optimization landscape suddenly changes. I had a super-cool trick for doing state transitions in a DFA at the rate of the throughput of a shuffle instruction rather than at the rate of the latency of a shuffle instruction, and smugly congratulated myself about how well it worked on Ivy Bridge (latency = 1, reciprocal throughput = 0.5). Then Haswell came along and took over the second shuffle capability to do 256-bit shuffles (latency = 1, throughput = 1). So the clever trick went obsolete overnight. :-(
- acdha 8y agoI remember a few stories like that back in the P3/P4/AMD era where a researcher ended up ripping out his hand-tuned assembly because the C reference implementation was increasingly faster. It was really good that they were very conscientious about testing both implementations regularly so there was zero concern about subtle incompatibility.