Hacker News Reader

Comment by gambiting | Hacker News Reader

>> Many games are pegged to one or two cores only

That hasn't been the case for a looong time. But to answer your question, they are much faster than anything from Intel at comparable pricing:

https://www.eurogamer.net/articles/digitalfoundry-2020-amd-r...

"The results here are immediately interesting. Despite costing less than every other CPU represented, the 3100 manages to tie the Core i5 9600K in single-core performance and outperform the Ryzen 2600 and 2700X by around 12 per cent. The 3300X is even more impressive, with a single-core score that exceeds the Core i7 9700K and only falls behind the Ryzen 9 3900X and Core i9 9900K."

View on HN

I have a Ryzen 3900X, and also an i5 for software development. With unoptimized code the Ryzen is pretty close to the i5. But when you start to really optimize it becomes obvious the i5 has more execution resources and is faster single threaded.

Is this including SPECTRE, etc. mitigations?

Why would anyone enable speculative execution mitigations on a computer used to build software?

because it's the default on most operating systems

Building software with lots of opensource libraries is effectively giving shell access to the authors of those libraries. They can stick whatever they like in those build scripts, and there's so many thousands of them I bet you don't check all of them by hand.

Given that, I'd prefer they had shell access as a low privilege user than be able to read my ssh keys from RAM...

Obviously if you compile software as your regular linux user account like most users, you're already a sitting duck, so might as well throw in a few more vulnerabilities.

Because you’re downloading lots of untrustable source from npm and friends when you are fetching your dependencies.

Yes default settings. The code we’re talking about is a hand rolled LZF decompressor originally written on the Ryzen 9 (so not intentionally Intel optimized).

Spectre doesn’t make much difference since its not making syscalls.

If you can somehow keep the CPU fed it becomes obvious there is more oomph behind the Intel device. That said how often are you running hand rolled assembly routines?

As an additional datapoint liblzf is faster on the Ryzen. But its limited by pipeline stalls so doesn’t get to take advantage of the extra resources.

I haven't looked at their newer offerings, but in years past that was definitely a problem that afflicted AMD -- having a fraction of the floating point execution units per core, creating AVX by adding an emulation layer over the existing SSE registers, etc. For a lot of use cases AMD could still be faster according to a wall clock (they weren't worse across the board -- those failings were used to purchase advantages in other chip features), but their peak flops were peanuts in comparison to the Intel offerings.

That part is fixed. They even eliminated most of the downclocking issues with the AVX units on Intel. AMD has been pretty tactical with Zen2.

The issues I’m talking about are execution resources for scalar code. Things like how many ALUs and which execution ports are able to execute which instructions.

When you optimize for maximum performance, leaving 11 cores idle is very sad.

If your algorithm is already parallel then you go back to making each core do more work per cycle.

Most benchmarks show the 3900X with single thread performance competitive with Intel's offerings, including for software whose developers spend plenty of time optimizing it. Can you think of a reason they haven't realized this performance advantage in practice?

Zen is great if you have moderate utilization code around the ~2-3 instructions per cycle mark. This is common for most compiled C and C++ where it hasn’t been specifically tuned for ILP. In these scenarios even if Intel has an extra ALU it won’t be used anyways.

It took 3 days of tuning to get to a point where Intel started pulling away from my Zen2 chip. No matter what I did the Zen2 would not get faster because it was already at max utilization.

Lemire had a blog [1] talking about this on here a few months ago as well. Most people were surprised because frankly Zen2 is very competitive with Intel for normal compiled code.

https://lemire.me/blog/2019/12/05/instructions-per-cycle-amd...

Are you measuring actual performance though or just IPC?

We know Intel has that problem with AVX-512. You can get a lot of throughput per cycle with those instructions but the cost is they cause the processor to run hot and have to downclock. It's possible (and really expected) that the same thing happens to some extent at unusually high IPC. Getting 15% higher IPC doesn't really buy you anything if the processor has to lower its clock speed by 15% to execute that type of code.

Actual wallclock time. The code is 100% scalar - LZF is very byte oriented and I haven't found a good way to vectorize it. IPC counts were used to help guide tuning but not a determination of success.

I don't really understand why people think this is controversial. Somehow an Intel cpu on a generation behind process is still competitive with a 7nm CPU with more cache. Intel must have one hell of an architecture to make that possible. AMD did a good job for the most common workloads but they have work to do with Zen3 if they want to maintain that lead when Intel finally figures out its manufacturing.

Have you looked at what 7zip is doing? That should be a similar type of code and it runs very well on Zen2.

7zip doesn't use LZF. LZF is mandated by the file format I'm working with.

Reply on news.ycombinator.com