Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket • Hacker News Board

Re: Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket

#91

Post by AngryData » Wed, Jul 18, 2018, 8:24 PM UTC

btgeekboy wrote: post #77

ScottBurson wrote: post #71

Come on, AnandTech! 3840GB != 3.84TB -- that's mixing binary and decimal systems. Say either 3840GB or 3840/1024 = 3.75TB.

They are correct here. TB is for decimal, TiB is for binary. https://en.m.wikipedia.org/wiki/Binary_prefix

"In 1998, the International Electrotechnical Commission IEC introduced the binary prefixes kibi, mebi, gibi"

But that hasn't stopped anyone because when talking about computers and data storage, unless you got some wacky old russian terenary system running in some bunker, everything should always be expressed using a base 2 system.

Re: Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket

#92

Post by AngryData » Wed, Jul 18, 2018, 8:33 PM UTC

quantumwoke wrote: post #10

I've weighed up the pros and cons, and my next processor will be the 32 core AMD cpu. This seems much better value than anything Intel has to offer.

Im in the same boat, my current processor I got was an intel specifically for the high single thread speed (a few performance heavy single thread games), but honestly the bit of extra clock speed hasn't really done it for me. The improvement is marginal compared to the ability to scale across cores and I expect pretty much everything I use now to take advantage of it. These days I have so many more programs concurrently open/in operation compared to the past, many of which are now fully capable of each using multiple cores, and I can still see myself using more. While my system isn't a spring chicken anymore I still have run into full system utilization a lot sooner and more often than I ever expected when I built this.

Re: Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket

#93

Post by xxs » Wed, Jul 18, 2018, 8:41 PM UTC

rbanffy wrote: post #86

xxs wrote: post #61

Earlier quoted context omitted.

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 memor…

> 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.

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.

Re: Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket

#94

Post by AnonymousR » Thu, Jul 19, 2018, 12:07 AM UTC

saati wrote: post #81

naveen99 wrote: post #76

Earlier quoted context omitted.

But pcie bus is shared with other cards. So 8 dimms is 8x faster than 8 pcie cards.

> But pcie bus is shared with other cards. No, it's not, that's the whole point of pcie, and dimms share the memory bus anyway, so the whole point is moot.

Well, it depends. "True" pcie slots do not share the bandwidth, but depending on available CPU lanes, which is awfully few in the last years on Intel - 16 lanes in top of the line i7? thats one graphics card - the slots are switched to 8x/8x, 8x/4x/4x and so on when populated.

M.2 slots are a whole another story, they are usually connected to the chipset instead of CPU on desktop motherboards (and finding this information for any particular board is difficult). The chipset is connected with CPU through DMI, which equals to pcie 4x and this is shared with everything on chipset - satas, gigabit ethernet, usb 3...

Re: Intel’s High-End Cascade Lake CPUs to Support 3.84 TB of Memory per Socket

#95

Post by rbanffy » Thu, Jul 19, 2018, 9:15 PM UTC

xxs wrote: post #93

rbanffy wrote: post #86

Earlier quoted context omitted.

> 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.

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.

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.