7 ms·
L1 cannot be too big and it should not grow any larger. L2 is a better option being 'only' 3 times slower than L1 (L1 tend to be ~3 clocks to read). L3 is an in
by xxs 8y ago
L1 cannot be too big and it should not grow any larger. L2 is a better option being 'only' 3 times slower than L1 (L1 tend to be ~3 clocks to read).
L3 is an interesting concept. Communication through L3 is quite beneficial in concurrent programming when done right; other than that it's there to hide the latency of accessing RAM. However, it's shared and easy to trash.
The software developers could do a lot for memory throughput hungry applications (datastructure layout, not using bloated strings for everything, not using linked lists, etc.), alas memory based optimizations almost never happen and tend to require a great deal of hardware understanding + non scripting language(s).
- rbanffy 8y ago> L1 cannot be too big and it should not grow any larger. L2 is a better option L1 and L2 grow linearly with the number of cores. If you have cores to burn, pinning processes makes a lot of sense.
- xxs 8y agorbanffy, it was meant per core. Counting L1/L2 across the entire die is rather pointless. Pinning makes most sense in NUMA indeed. Nowadays my impression is that often times the multicore/socket hardware tend to be chopped down by virtual machines, though.
- rbanffy 8y agoIf you use VMs and don't pin VMs to cores (which is pretty sensible) yes, but if you run your processes on your metal, pinning processes will reduce pressure on their L1/L2 caches if a given process is running on it constantly, the odds the caches have the "right" data increase. The same goes for the processes that are not pinned, as they don't need to compete with the pinned one (unless they have the misfortune of being scheduled on those cores). In the end, it'll look like your cache is bigger.