3 ms·

An instruction account would be a decent first order approximation, but I don't think it will be very useful for optimization. The bottleneck of modern hardwar

An instruction account would be a decent first order approximation, but I don't think it will be very useful for optimization. The bottleneck of modern hardware (generally) is memory. You can get huge speedups by tweaking the way your program structures and operates on data to make it more cache friendly. This won't really affect instruction count but could make your program run 2x faster.

hinkley 4y ago
I have been wondering for a while if the solution to the memory bottleneck is to stop treating cache memory as an abstraction and make it directly addressable. Removing L1 cache is probably impossible, but I suspect removing L2 and L3 caches and replacing them with working memory might fare better. The latest iteration of this thought process was wondering what would happen if you exposed microcode for memory management to the kernel, and it ran a moral equivalent of eBNF directly in a beefed up MMU. Legacy code and code that doesn't deign to do its own management would elect to use routines that maintain the cache abstraction. The kernel could also segment the caches for different processes, reducing the surface area for cache-related bugs.
lesuorac 4y ago
Somebody else pointed out that I probably want to use Valgrind. It seems to have the ability to count instruction counts as well as cache misses [1] [2]. [1]: https://web.stanford.edu/class/archive/cs/cs107/cs107.1202/resources/callgrind https://web.stanford.edu/class/archive/cs/cs107/cs107.1202/r... [2]: http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-rust-programs-on-linux/ http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-...
- dahfizz 4y ago
  Yup! valgrind is an amazing tool. Just keep in mind that the program itself will be slower when run under valgrind. Its great for debugging, but your benchmarks should be run raw.
  - dmit 4y ago
    And when all else fails, you reach for Intel VTune. :) Which has provided a free community version for a couple years now, I might add.

hinkley 4y ago

I have been wondering for a while if the solution to the memory bottleneck is to stop treating cache memory as an abstraction and make it directly addressable. Removing L1 cache is probably impossible, but I suspect removing L2 and L3 caches and replacing them with working memory might fare better. The latest iteration of this thought process was wondering what would happen if you exposed microcode for memory management to the kernel, and it ran a moral equivalent of eBNF directly in a beefed up MMU. Legacy code and code that doesn't deign to do its own management would elect to use routines that maintain the cache abstraction. The kernel could also segment the caches for different processes, reducing the surface area for cache-related bugs.

lesuorac 4y ago

Somebody else pointed out that I probably want to use Valgrind. It seems to have the ability to count instruction counts as well as cache misses [1] [2]. [1]: https://web.stanford.edu/class/archive/cs/cs107/cs107.1202/resources/callgrind https://web.stanford.edu/class/archive/cs/cs107/cs107.1202/r... [2]: http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-rust-programs-on-linux/ http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-...

dahfizz 4y ago
Yup! valgrind is an amazing tool. Just keep in mind that the program itself will be slower when run under valgrind. Its great for debugging, but your benchmarks should be run raw.
- dmit 4y ago
  And when all else fails, you reach for Intel VTune. :) Which has provided a free community version for a couple years now, I might add.