Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

anandtech.com

Post reply on HN
Print view View original

81–90 of 95 posts

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

#81

Post by saati »

naveen99 wrote: post #76
tgtweak wrote: post #34

Earlier quoted context omitted.

DDR4 dimm read throughput is about 20GB/s per dimm. PCIe 3.1 x4 is 16GB/s. I feel very comfortable claiming that these optane dimms will not reach 20GB/s of sustained performance. The advantage here being latency (and thus single queue throughput)

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.

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

#82

Post by Rafuino »

ksec wrote: post #43

What I really wanted to know is the performance difference in Postgre / MySQL, between 128GB of DRAM, with 1TB of SSD, 1TB of Optane via PCI-E, and Optane DIMM.

You can find various benchmarks and testing results here: https://www.acceleratewithoptane.com/stories. We're working on some Postgre, or I invite you to do some benchmarking yourself on our community lab.

Disclosure: I work at Intel partly with the Optane SSDs (the PCIe version you mention).

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

#83

Post by naveen99 »

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.

Hmm. In that case never mind.

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

#84

Post by bumblebritches5 »

theevilsharpie wrote: post #25
opportune wrote: post #21

Earlier quoted context omitted.

They probably felt pressured to release that because the next gen thread rippers are actually going to approach those specs: 32 core 3.8 (base) GHz as per https://www.techradar.com/news/amd-ryzen-threadripper-2nd-ge... supposedly coming out in Q3, i.e. soon

Threadripper may come close in core count, but it cannot use registered memory, which means it's limited to 128 GB of RAM (based on the current maximum UDIMM capacities). That's not competitive in the server space.

Threadripper is not a server CPU, it's a HEDT CPU.

Epyc is the server CPU line.

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

#85

Post by rbanffy »

gameswithgo wrote: post #57
rbanffy wrote: post #56

Earlier quoted context omitted.

If we can balance the L1 cache eviction rate for the extra cores (since L1 is not shared), memory bandwidth pressure will be lower. These monsters also have a lot of memory channels to address memory hunger. I still think we can push the envelope a bit further for most common desktop software.

There is definitely room to improve how often and efficiently desktop software utilizes more cores, but I don't expect it will be common that ~32 cores gets you much gain over ~8. But when you do have a workload that can benefit, like if you know GCC will compile a huge c++ project linearly faster up to 32 cores, then it is VERY welcome!

If you have cores to spare, you can do incremental compilation every time you save a file. You can also do a lot of speculative work that may be thrown away but, in case it's needed, it's already done.

There is no such thing as too many cores ;-)

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

#86

Post by rbanffy »

xxs wrote: post #61
rbanffy wrote: post #56

Earlier quoted context omitted.

If we can balance the L1 cache eviction rate for the extra cores (since L1 is not shared), memory bandwidth pressure will be lower. These monsters also have a lot of memory channels to address memory hunger. I still think we can push the envelope a bit further for most common desktop software.

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.

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

#87

Post by llampx »

imtringued wrote: post #45
throwaway2048 wrote: post #6

Earlier quoted context omitted.

Intel keep positioning optane as "close to dram" preformance (especially with misleading marketing nonsense like this), it does have some advantages over flash, mostly related to random access times, but its nowhere near the orders of magnitude more preformant that something would require to fill the preformance point between DRAM and SSDs. Optane is almost entirely hype, with no substance.

I don't see how a first generation product with similar performance and superior latency to a mature technology (nand) that took decades to develop has no substance. The second generation of Optane is coming out this year and it's going to be an order of magnitude better. It's just a matter of time until nand is obsolete.

If Optane is Intel-only, it is not going to replace NAND.

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

#88

Post by dragontamer »

tgtweak wrote: post #34
naveen99 wrote: post #30

Earlier quoted context omitted.

I thought the real advantage of Optane was bypassing the pcie bus, with much larger bandwidth of dimm: 80GB/s instead of 12GB/s

DDR4 dimm read throughput is about 20GB/s per dimm. PCIe 3.1 x4 is 16GB/s. I feel very comfortable claiming that these optane dimms will not reach 20GB/s of sustained performance. The advantage here being latency (and thus single queue throughput)

> PCIe 3.1 x4 is 16GB/s

PCIe x4 is 3.94GB/s. PCIe x16 is 15.76GB/s.

> DDR4 dimm read throughput is about 20GB/s per dimm

Per channel, not per dimm. Two dimms typically go into a singular channel.

> The advantage here being latency (and thus single queue throughput)

Agreed

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

#89

Post by Const-me »

ajross wrote: post #52
cmsimike wrote: post #48

Earlier quoted context omitted.

As far as I know, Ryzen has avx-256, its four 128bit units can join as two 256 bit ones without any penalty. What makes this not real AVX? Because there is not one dedicated 256-bit unit?

> without any penalty Except literally running at half capacity. That doesn't qualify as a "penalty" to you? The point was that AMD advertised support for AVX in a context where you'd expect it to be performance-comparable, and what they shipped was "support" for AVX in the sense that the code wouldn't crash, but wouldn't provide any performance benefit over SSE either.

> Except literally running at half capacity.

I’ve been writing SIMD code for some time now, and I disagree.

You can read the documentation I’ve generated https://github.com/Const-me/IntelIntrinsics AVX intrinsics begin with _mm256_.

You’ll find that for some AVX operations, such as _mm256_fmadd_ps, _mm256_adds_epi8, _mm256_blendv_ps, both latency and throughput of Ryzen is equivalent to Skylake. For some others, e.g. _mm256_add_ps, _mm256_mul_ps, Ryzen is close to some older Intel, Haswell or Broadwell. Only for very rarely used stuff, e.g. _mm256_broadcast_ps, _mm256_madd_epi16, Ryzen is significantly slower than Intel.

Post reply on HN