5 ms·

Conversely cache misses are painful and largely haven't gotten faster over the years.

mbreese 8y ago
Exactly. And the reason why programs that use a lot of memory might feel slower than one with a little is that cache miss rate. Adding memory often makes an entire system faster (again, because you can cache things in the faster RAM rather than paging out to disk). But for two comparable programs, I could see the argument that the lower-memory footprint program would be faster. (For comparable programs).
- vvanders 8y ago
  Yup, as DDR clock speed increased so have CAS timings.
- fwip 8y ago
  If the algorithms are otherwise identical, sure. Often the memory being used is doing things like pre-loading information from disk or the network before it's needed, or caching results for reuse. Or it's storing the information in a faster but less dense data structure - kind of like denormalizing a database for performance reasons.
segfaultbuserr 8y ago
It's a serious problem in compiler optimization. In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. Time goes by, and compilers keep adding increasingly complex techniques based on space/time tradeoffs, making the problem trickier. Historically, under some circumstances, a problem compiled with -Os, may paradoxically be faster than -O2, and -O2 may be faster than -O3. I think the situation is getting better now, and the optimizing level mostly works as advertised. But there's still some problems in automatic loop vectorization.
- greglindahl 8y ago
  What's the paradox? The compiler simply can't tell.
- 0815test 8y ago
  > In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. The solution is to use abstract, arbitrary vectors in the ISA instead of packed SIMD and unrolled loops. RISC-V gets this right with their V extension.
  - greglindahl 8y ago
    There are many different kinds of loop unrolling, and RISC-V's V extension is not the only one. Itanium had the same issue: the loop unrolling assist in the instruction set was not viewed by many compiler people as being sufficient.
  - colejohnson66 8y ago
    ForwardCom has abitrary length vector support. http://www.forwardcom.info/ http://www.forwardcom.info/ https://news.ycombinator.com/item?id=19340267 https://news.ycombinator.com/item?id=19340267

Exactly. And the reason why programs that use a lot of memory might feel slower than one with a little is that cache miss rate. Adding memory often makes an entire system faster (again, because you can cache things in the faster RAM rather than paging out to disk). But for two comparable programs, I could see the argument that the lower-memory footprint program would be faster. (For comparable programs).

vvanders 8y ago
Yup, as DDR clock speed increased so have CAS timings.
fwip 8y ago
If the algorithms are otherwise identical, sure. Often the memory being used is doing things like pre-loading information from disk or the network before it's needed, or caching results for reuse. Or it's storing the information in a faster but less dense data structure - kind of like denormalizing a database for performance reasons.

segfaultbuserr 8y ago

It's a serious problem in compiler optimization. In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. Time goes by, and compilers keep adding increasingly complex techniques based on space/time tradeoffs, making the problem trickier. Historically, under some circumstances, a problem compiled with -Os, may paradoxically be faster than -O2, and -O2 may be faster than -O3. I think the situation is getting better now, and the optimizing level mostly works as advertised. But there's still some problems in automatic loop vectorization.

greglindahl 8y ago
What's the paradox? The compiler simply can't tell.
0815test 8y ago
> In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. The solution is to use abstract, arbitrary vectors in the ISA instead of packed SIMD and unrolled loops. RISC-V gets this right with their V extension.
- greglindahl 8y ago
  There are many different kinds of loop unrolling, and RISC-V's V extension is not the only one. Itanium had the same issue: the loop unrolling assist in the instruction set was not viewed by many compiler people as being sufficient.
- colejohnson66 8y ago
  ForwardCom has abitrary length vector support. http://www.forwardcom.info/ http://www.forwardcom.info/ https://news.ycombinator.com/item?id=19340267 https://news.ycombinator.com/item?id=19340267