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

51–60 of 95 posts

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

#51

Post by gameswithgo »

cmsimike wrote: post #48
gameswithgo wrote: post #40

Earlier quoted context omitted.

AMD is guilty of it as well. "AVX2" -> not really! But yes I do wish them well. Make the avx support real AMD!

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.

My understanding is that without any penalty was not true, but it is possible the new gen cpus have changed that, I have not firsthand benchmarked it.

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

#52

Post by ajross »

cmsimike wrote: post #48
gameswithgo wrote: post #40

Earlier quoted context omitted.

AMD is guilty of it as well. "AVX2" -> not really! But yes I do wish them well. Make the avx support real AMD!

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.

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

#53

Post by ajross »

aoeusnth1 wrote: post #37
theevilsharpie wrote: post #25

Earlier quoted context omitted.

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.

Why does threadripper need to be competitive in the server space? Edit: emphasis on threadripper , which is a consumer product.

Because laptop CPUs don't make any money, and gaming PCs are so small a market as to be irrelevant. The bulk of x86 revenue, and almost all the profit, is in the datacenter.

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

#54

Post by gameswithgo »

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.

oh, they are twisting words with the marketing about "no penalty" pretty bad!

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

#55

Post by aoeusnth1 »

ajross wrote: post #53
aoeusnth1 wrote: post #37

Earlier quoted context omitted.

Why does threadripper need to be competitive in the server space? Edit: emphasis on threadripper , which is a consumer product.

Because laptop CPUs don't make any money, and gaming PCs are so small a market as to be irrelevant. The bulk of x86 revenue, and almost all the profit, is in the datacenter.

Right. But threadripper isn’t AMD’s server processor, and EPYC is eating Intel’s lunch.

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

#56

Post by rbanffy »

gameswithgo wrote: post #44
rbanffy wrote: post #35

Earlier quoted context omitted.

I'd love to see more popular processors with high core count, even if at the cost of single thread performance. When even a phone CPU has 8 cores, being able to use the parallelism on the stuff we normally don't use it would improve life for everyone. And, with high core counts, we can start playing with things like dedicating cores (and their L1 caches) to single tasks, kind of specializing them as we do with mainfr…

as core count goes up the number of tasks that can be sped up starts to shrink, because memory access and throughput become more and more of a limiter. That is why you tend to see huge l3 caches on the big core cpus, it helps but it can still be a challenge to load up all 32 cores and get any speedup, for many workloads. l3 cache is not THAT much faster than ram. that is why I tend to eye the ~6 core machines for des…

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.

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

#57

Post by gameswithgo »

rbanffy wrote: post #56
gameswithgo wrote: post #44

Earlier quoted context omitted.

as core count goes up the number of tasks that can be sped up starts to shrink, because memory access and throughput become more and more of a limiter. That is why you tend to see huge l3 caches on the big core cpus, it helps but it can still be a challenge to load up all 32 cores and get any speedup, for many workloads. l3 cache is not THAT much faster than ram. that is why I tend to eye the ~6 core machines for des…

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!

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

#58

Post by spacentropy »

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.

Here's some benchmark for MySQL, SSD vs Optane (Intel vs Intel): http://dimitrik.free.fr/blog/posts/mysql-performance-80-ga-i...

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

#59

Post by hajile »

gameswithgo wrote: post #40
nottorp wrote: post #5

Earlier quoted context omitted.

Yeah, marketing lies. Go AMD go!

AMD is guilty of it as well. "AVX2" -> not really! But yes I do wish them well. Make the avx support real AMD!

AVX2 is a set of instructions and AMD supports them. How they support them is a different question. Does Intel not support AVX512 because their processors run at a lower clockspeed when they execute? There are more and less efficient ways to support an instruction set.

AMD decided that consistent clockspeeds were more important than wider units. They decided that most users won't use enough AVX instructions to overwhelm the AVX unit (especially with consistent clocks), so there was no justification in ballooning the die size and increasing power consumption without a decent payoff.

https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#New...

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

#60

Post by hajile »

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.

https://en.wikichip.org/wiki/intel/frequency_behavior

Intel reduces clockspeeds when running AVX2 and drastically decreases clockspeeds when running AVX512. AMD's slightly smaller unit doesn't need to slow down, so the actual performance difference is smaller than it would appear.

Changing frequency takes time. Also, if you are putting through an AVX instruction and a few integer instructions at the same time, the integer instructions will downclock the whole time the AVX pipeline is in use (plus the time before/and after while the clockspeed is being adjusted) decreasing performance for more than just the AVX.

There are a couple articles written on the topic. Here's one.

https://blog.cloudflare.com/on-the-dangers-of-intels-frequen...

https://software.intel.com/en-us/forums/intel-isa-extensions...

Post reply on HN