News for hackers. Stuff that matters.

A comment on Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket. Parent comment

Re:Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of ... by xxs on Tuesday July 17, 2018 @11:44AM (#17550470)
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).

[ Parent | on HN ]
Re:Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of ... by rbanffy on Tuesday July 17, 2018 @04:28PM (#17553037)
> 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.

[ Parent | on HN ]
Re:Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of ... by xxs on Wednesday July 18, 2018 @04:41PM (#17561888)
rbanffy, 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.

[ Parent | on HN ]
Re:Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of ... by rbanffy on Thursday July 19, 2018 @05:15PM (#17570346)
If 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.
[ Parent | on HN ]