3 ms·
I think having a ballpark intuition for disk/SSD reads and long network packets is possibly useful to a lot of devs. Much beyond that it's academic unless you r
by jariel 6y ago
I think having a ballpark intuition for disk/SSD reads and long network packets is possibly useful to a lot of devs. Much beyond that it's academic unless you really need to know.
- H8crilA 6y agoIt's also good to know th relative costs of memory systems. My rule of thumb, based on market prices: RAM:SSD:Magnetic - 100:10:1 For example 10 terabytes of RAM costs as much as 1 petabyte of spinning disk magnetic storage.
- pvg 6y agoI think this is inadvertently a good critique of this popular item - it doesn't really tell you why you might want to have some exposure to these numbers. For a lot of programming, the lowest of these latencies - cache and memory access and branch mispredicts are averaged out and essentially unnoticeable or not worth caring too much about. Which is to be expected, being the design goal. But it's not too rare, even in regular, high-level language programming for them to become 'macroscopic' and that is a useful, practical thing to be aware of, rather than some academic curiosity.
- dragontamer 6y agoI think you underestimate the domination of large numbers. Let's say you have code that is 50% main memory and 50% L1 cache. Let's say there are 1000 operations. You have (500 x 100ns) + (500 x 1ns) or 50500ns total time. Now let's say you optimize the code so that they are all L3 operations: 20ns x 1000 operations is 20000ns, or over twice as fast.
- pvg 6y agoI'm not sure I'm underestimating anything since I'm not estimating things and we seem to be kind of saying the same thing? Edit: to clarify a bit further - people read this list and think '1 nanosecond, 5 nanoseconds, not important to me, academic, etc'. My point is that's a misunderstanding but the list alone doesn't do a good job of disabusing one of the misunderstanding.
- andi999 6y agoIf you optimizen for L1-L3 caches you need to know/control what hardware you are running on since cache sizes differ between processors, isnt it?
- oriolid 6y agoOften you can get pretty good results from just knowing that cache misses are expensive and working from that point: Store together what is accessed together, use linear arrays to help prefetcher, prefetch manually if really needed (it usually isn't and the prefetch instruction isn't free), if your data is accessed effectively randomly try packing used parts into smaller amount of cache lines, etc... The latency numbers are still useful for making back of the envelope calculations about how much it is possible to gain and whether it's worth the trouble.
- andi999 6y agoCan you explain the radomly accessing data cache mitigation strategy more?
- oriolid 6y agoWell, it doesn't work if the access is so random that everything is guaranteed cache miss. On the other hand, if there's a subset that's accessed more often than rest, it reduces cache pollution from accessing outside the core subset.
- mjevans 6y agoIf it's this random it might be worth stepping back and trying to figure out how to get the portion of the results that are desired using a more effective mechanism. Sometimes the source data structure is just a bad fit for the expressed data. I've seen this often in combinatorial expansions of data stored in hierarchal structure to a 2d table. Sometimes all, or a majority, of the data is going to be touched anyway so it's more costly to avoid a full read and instead more optimal to make the results of that read parallel; either by sorting to a more suitable structure or by working on streams / permutations / parallel processes from a dispatch design.