Following a link from @Bortzmeyer, I was leafing through Felix von Leitner’s “Source Code Optimization” – a presentation demonstrating how unreadable code is rarely worth the hassle considering how good at optimizing compilers have become nowadays. I have never written a single line of C or Assembler in my whole life – but I like to keep an understanding of what is going on at low level so I sometimes indulge in code tourism.
I got the author’s point, though I must admit that the details of his demonstration flew over my head. But I found the memory access timings table particularly evocative :
|Page Fault, file on IDE disk||1.000.000.000 cycles|
|Page Fault, file in buffer cache||10.000 cycles|
|Page Fault, file on ram disk||5.000 cycles|
|Page Fault, zero page||3.000 cycles|
|Main memory access||200 cycles (Intel says 159)|
|L3 cache hit||52 cycles (Intel says 36)|
|L1 cache hit||2 cycles|
Of course you know that swapping causes a huge performance hit and you have seen the benchmarks where throughput is reduced to a trickle as soon as the disk is involved. But still I find that quantifying the number of cycles wasted illustrates the point even better. Now you know why programmers insist on keeping memory usage tight.