4 ms·
Its still a huge concern. Cache today is what memory was in the 80s and 90s. Memory today is what disk was. And your L1 cache today might be 64kb! That’s basica
by alkonaut 4y ago
Its still a huge concern. Cache today is what memory was in the 80s and 90s. Memory today is what disk was. And your L1 cache today might be 64kb! That’s basically what you can work with if you want to use your CPU at full speed.
For anything that isn’t IO bound you are very often bound by memory access time. CPUs are incredibly fast and feeding them data to work on is very difficult, more so today than before!
The big difference is that a category of programming jobs has appeared where this is almost never a concern because it’s about shoving text around between servers.
- throw_away_8080 4y agoI have changed a program to use a smaller struct in a recursive function call and improved the speed significantly. I did measure so I can't say why for sure, but it was satisfying to see the exact same algorithm go faster. I assume it was because it had better cache performance.
- nextaccountic 4y agoA lot of effort is spent to reduce the size of structs in the Rust compiler https://nnethercote.github.io/2023/03/24/how-to-speed-up-the-rust-compiler-in-march-2023.html#ast-shrinkage https://nnethercote.github.io/2023/03/24/how-to-speed-up-the... 3% and 6% of improvement doesn't seem like much, but at the level of rustc those big wins Performance of Rustc must be continously tracked (here https://perf.rust-lang.org/ https://perf.rust-lang.org/) because if you don't proactively fight against bloat, the tendency is that the code will become slower over time (due to new features etc)
- shortrounddev 4y ago> For anything that isn't IO bound It seems like most things are web services these days though