Live data from Hacker News

Unexpected benefit with Ryzen – reducing power for build server

lists.dragonflybsd.org

31–40 of 61 posts

Re: Unexpected benefit with Ryzen – reducing power for build server

#31
post #12

Earlier quoted context omitted.

I was talkin about Ryzen 8core more actually. Those have low clock speed. And are called EPYC.

Got it. For what it's worth I think EPYC is based on the same "Zen" arch as Ryzen.

With a bit enhanced memory controller, Zen refresh (2xxx) should do a bit better still.

Re: Unexpected benefit with Ryzen – reducing power for build server

#32

Earlier quoted context omitted.

Epyc is the name for the server chips. Both Ryzen and Epyc are based on the same microarchitecture.

Both based on Zen. Still I wanted the high-clock-core and not the hundred-slow-cores.

In that case, Threadripper is the core that is inbetween.

Re: Unexpected benefit with Ryzen – reducing power for build server

#33

Not every workload is memory bandwidth bound like his "make -j16" compile. Some workloads need memory latency or fast inter-core (and inter-socket) operations (e.g. RDBMS OLTP), some need CPU throughput (e.g. HPC), some need best possible single thread CPU performance (e.g. some gaming). As he wrote, CPUs are most efficient (compute per Watt) at a specific frequency, and if his CPU mostly waits for RAM, this can be d…

Zen is already light on vector units, and microcodes 256-bit operations. It's certainly possible to build a more lightweight core, but most of that work is reducing the complexity of the out-of-order machinery. The FPU+ALU is under a quarter of each Zen core. https://en.wikichip.org/w/images/c/cb/amd_zen_core_%28annota...

Do you have a link about microcoded avx256? I would think it would be way too slow.

Re: Unexpected benefit with Ryzen – reducing power for build server

#34
This is to be expected. Since 180Watt is not the default TDP of Ryzen 2700X, the default TDP is 105Watt. https://www.amd.com/en/products/cpu/amd-ryzen-7-2700x

Which mean the CPU is already shipped with the reasonable performance/watt TDP and over-TDP it will give diminish return in performance gain.

However, It would be interesting to see benchmark in much lower TDP than 105Watt and see how far the TDP can go down before big drop in performance.

Re: Unexpected benefit with Ryzen – reducing power for build server

#35
post #33

Earlier quoted context omitted.

Zen is already light on vector units, and microcodes 256-bit operations. It's certainly possible to build a more lightweight core, but most of that work is reducing the complexity of the out-of-order machinery. The FPU+ALU is under a quarter of each Zen core. https://en.wikichip.org/w/images/c/cb/amd_zen_core_%28annota...

Do you have a link about microcoded avx256? I would think it would be way too slow.

> 256-bit vector instructions (AVX instructions) are split into two micro-ops handling 128 bits each.

https://www.agner.org/optimize/blog/read.php?i=838#838

This is responsible for Ryzen losing to Intel in SIMD heavy benchmarks. The upside is that it avoids the reduced turbo boost Intel does for some 256-bit AVX instructions (and even worse downclocks caused by AVX 512), so for workloads mixing avx and normal instructions it shouldn't do too badly.

Re: Unexpected benefit with Ryzen – reducing power for build server

#36
post #33

Earlier quoted context omitted.

Do you have a link about microcoded avx256? I would think it would be way too slow.

> 256-bit vector instructions (AVX instructions) are split into two micro-ops handling 128 bits each. https://www.agner.org/optimize/blog/read.php?i=838#838 This is responsible for Ryzen losing to Intel in SIMD heavy benchmarks. The upside is that it avoids the reduced turbo boost Intel does for some 256-bit AVX instructions (and even worse downclocks caused by AVX 512), so for workloads mixing avx and normal instruc…

I see, yep - but this is still hardwired stuff happening in instruction decode, as Agner writes, not trapping to microcode sequencing.

Re: Unexpected benefit with Ryzen – reducing power for build server

#37

I think the claim that parallel compilation with gcc is memory bandwidth bound is unlikely. gcc is known to be a very pointer-chasy, branch-mispredicty load that is highly sensitive to memory latency - far from a streaming load that is sensitive to raw bandwidth. Still, the conclusion holds: if most of the time is spent waiting for values to come back from memory, a higher core frequency has strongly diminishing retu…

I wonder if his results still hold for gcc -O3?

That be much more CPU-bound. Yes - some optimization will do global traversals.

I wonder if javac/clang has the same characteristics as gcc.

Re: Unexpected benefit with Ryzen – reducing power for build server

#39
post #36

Earlier quoted context omitted.

> 256-bit vector instructions (AVX instructions) are split into two micro-ops handling 128 bits each. https://www.agner.org/optimize/blog/read.php?i=838#838 This is responsible for Ryzen losing to Intel in SIMD heavy benchmarks. The upside is that it avoids the reduced turbo boost Intel does for some 256-bit AVX instructions (and even worse downclocks caused by AVX 512), so for workloads mixing avx and normal instruc…

I see, yep - but this is still hardwired stuff happening in instruction decode, as Agner writes, not trapping to microcode sequencing.

Is there a good resource that explains the difference between those ("decode" vs. "trapping") on a modern CPU? When I see "trap" I imagine the kernel catching illegal instruction exceptions and emulating them in software, but it doesn't seem like that's what you mean?

Re: Unexpected benefit with Ryzen – reducing power for build server

#40

I think the claim that parallel compilation with gcc is memory bandwidth bound is unlikely. gcc is known to be a very pointer-chasy, branch-mispredicty load that is highly sensitive to memory latency - far from a streaming load that is sensitive to raw bandwidth. Still, the conclusion holds: if most of the time is spent waiting for values to come back from memory, a higher core frequency has strongly diminishing retu…

That's only true if you only compile a single file at once which is an exceedingly rare use case for a build server. As soon as you compile files in parallel the CPU can simply switch to the next hardware thread during a memory load from main memory. Then there is the fact that dual channel DDR4 just doesn't provide a lot of memory bandwidth in the first place. A 16 core/32 thread desktop CPU is probably not going to happen on the AM4/Ryzen platform even if everything suddenly supports multi-threading on 16 cores simply because the memory bandwidth isn't enough to translate into meaningful performance increases. GPUs have horrendous memory latencies but they perform well precisely because they can just switch to the next thread and execute that one while waiting.
Post reply on HN