5 ms·

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

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.

ccffpphh 6y ago
Is this including SPECTRE, etc. mitigations?
- jeffbee 6y ago
  Why would anyone enable speculative execution mitigations on a computer used to build software?
  - monotypical 6y ago
    because it's the default on most operating systems
  - londons_explore 6y ago
    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.
  - josteink 6y ago
    Because you’re downloading lots of untrustable source from npm and friends when you are fetching your dependencies.
- jdsully 6y ago
  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.
hansvm 6y ago
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.
- jdsully 6y ago
  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.
pornel 6y ago
When you optimize for maximum performance, leaving 11 cores idle is very sad.
- jdsully 6y ago
  If your algorithm is already parallel then you go back to making each core do more work per cycle.
deleted 6y ago
[deleted]
zrm 6y ago
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?
- jdsully 6y ago
  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-versus-intel/ https://lemire.me/blog/2019/12/05/instructions-per-cycle-amd...
  - zrm 6y ago
    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.
    - jdsully 6y ago
      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.

ccffpphh 6y ago

Is this including SPECTRE, etc. mitigations?

jeffbee 6y ago
Why would anyone enable speculative execution mitigations on a computer used to build software?
- monotypical 6y ago
  because it's the default on most operating systems
- londons_explore 6y ago
  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.
- josteink 6y ago
  Because you’re downloading lots of untrustable source from npm and friends when you are fetching your dependencies.
jdsully 6y ago
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.

hansvm 6y ago

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.

jdsully 6y ago
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.

pornel 6y ago

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

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

deleted 6y ago

[deleted]

zrm 6y ago

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?

jdsully 6y ago
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-versus-intel/ https://lemire.me/blog/2019/12/05/instructions-per-cycle-amd...
- zrm 6y ago
  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.
  - jdsully 6y ago
    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.