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

Unexpected benefit with Ryzen – reducing power for build server

lists.dragonflybsd.org

Post reply on HN
Print view View original

51–60 of 61 posts

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

#51

Post by BeeOnRope »

imtringued wrote: post #40
BeeOnRope wrote: post #23

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…

Well you are mixing the effect of "more cores" and SMT together here. Sure, SMT helps hide some latency effects, but it doesn't significantly increase the demand for bandwidth. The increased bandwidth requirements when introducing SMT are probably approximately modeled by the increase in performance: so a 30% uplift from running two hardware threads per core means that bandwidth requirement increases by about 30%.

That's not enough to turn gcc from a largely latency bound load to a memory bandwidth hog!

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

#52

Post by BeeOnRope »

AstralStorm wrote: post #30
BeeOnRope wrote: post #23

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…

Closer to zero returns and you still get to improve latency hiding and memory controller design. (including bit width and block sizes) Even more cache ways won't help too much in this workload.

Unless the AMD design is unusual it is not very close to zero return: a significant part of the "path to memory" involves things run at the core clock, in particular everything from the core to the L2 and probably some part of the coordination logic which communicates with the "uncore". I'm not sure about AMD chips, but on some chips there is a relationship between the uncore speed and the core speed: e.g., the uncore speed might often be the same as the maximum core speed for any core on the socket.

Adding to that, there are other effects that allow core frequency to leak into the performance of memory-bound programs, such as a higher frequency allowing the core run ahead more quickly to get more memory requests in flight, recover more quickly after a branch misprediction, etc. Try it sometime: find something which is really memory bound and crank the frequency way down: there will probably be a significant effect, but not nearly in proportion to the frequency difference.

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

#53

Post by BeeOnRope »

yazr wrote: post #37
BeeOnRope wrote: post #23

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.

Yeah maybe. I haven't found a huge difference between -O3 and -O2, but maybe I haven't been running big enough compiles.

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

#54

Post by BeeOnRope »

Dylan16807 wrote: post #22
wolf550e wrote: post #17

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

It is definitely not "microcoded" - 256-bit operations are just sent in halves to the 128-bit ALUs and combined for the final answer.

Don't get mixed up between "microcoding" and "micro-op" - the latter is something different, slower and which usually requires some kind of transition in the decoders and uop caches to start reading microcoded ops. The latter is the "normal" or "fast" mode for the CPU and just because one instruction turns into two uops (or macro-ops or whatever AMD calls them) doens't mean microcoded.

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

#55

Post by BeeOnRope »

randomthrow1 wrote: post #48
wolf550e wrote: post #17

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…

I'm interested in performance optimization (especially under linux) and its intersection with computer architecture. Would you mind recommending me any resources to get started there?

For x86 specifically, Agner Fog's manual, the Intel and AMD optimization manuals, the SO x86 tag wiki [1].

[1] https://stackoverflow.com/tags/x86/info

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

#56

Post by morsma »

dman wrote: post #21
ddorian43 wrote: post #19

Earlier quoted context omitted.

Please see other comments. It's EPYC and not RYZEN. 2.0 Ghz base clock speed is not nice for single-thread.

For compilation it is a beast. Built a dual 7551 Epyc workstation for myself recently, it builds llvm in ~160 seconds from scratch. https://openbenchmarking.org/result/1809030-AR-DUAL7551867

God damn that's a beast!

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

#57

Post by randomthrow1 »

BeeOnRope wrote: post #55
randomthrow1 wrote: post #48

Earlier quoted context omitted.

I'm interested in performance optimization (especially under linux) and its intersection with computer architecture. Would you mind recommending me any resources to get started there?

For x86 specifically, Agner Fog's manual, the Intel and AMD optimization manuals, the SO x86 tag wiki [1]. [1] https://stackoverflow.com/tags/x86/info

That's a great idea, thank you!

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

#58

Post by afandian »

BeeOnRope wrote: post #16
ddorian43 wrote: post #2

Any server-hosting with Ryzen + ecc-ram ?

Packet.net offers it: https://www.packet.net/bare-metal/servers/c2-medium-epyc/

Do you have experience with packet.net ? There's virtually no discussion on HN, which I find surprising.

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

#59

Post by jandrese »

tgtweak wrote: post #46
manual wrote: post #42

Earlier quoted context omitted.

Excellent look into this by user "The Stilt" can be found here: https://forums.anandtech.com/threads/ryzen-strictly-technica... It looks something like this: 4GHz 120W, 3.8 90W, 3.6 65W, 3.4 50W, 32 42W, 3.0 33W, 2.0 13W. This excludes the SOC.

Stilt is a magician in getting peak performance per watt out of everything. Down to tweaking individual straps for memory timing on binary firmwares for amd graphics cards. 3.6 @65W is impressive, almost stock speed at nearly half tdp.

Basically a 10% performance penalty for a 45% power savings. And you might not even see that 10% performance penalty if you're machine is bottlenecked on memory/storage.

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

#60

Post by Fnoord »

BeeOnRope wrote: post #14
magila wrote: post #7

Calling this "Unexpected" seems like a bit of a stretch. In particular this part: > Of course, in the server space, we've known for a long time that maximum efficiency occurs with a high number of cores running at lower frequencies, and that efficiency trumps performance on machines with high core counts. But I never considered that the consumer Ryzen CPUs could also benefit from the same thing until now. makes no se…

Well I suppose the part that might not apply to desktop parts is "efficiency trumps performance". Many desktop uses don't care about efficiency, but care about performance. For servers, the purchasing decisions are probably much more quantitative, and if you are buying a high core count machine it probably means you have a parallelizable workload, so no efficiency comes into play since you have a lot of choice on the…

> Many desktop uses don't care about efficiency, but care about performance.

Why not? I like it when my electricity bill is less severe. For my wallet and the environment alike.

Post reply on HN