6 ms·

Exactly. About 780Gflops/$ for Tesla V100 and 460Gflops/$ (peak) for the Epyc 7742. I was very surprised it was this close. I thought the accelerator would be

Exactly. About 780Gflops/$ for Tesla V100 and 460Gflops/$ (peak) for the Epyc 7742. I was very surprised it was this close. I thought the accelerator would be an order of magnitude cheaper per double Gflop. And AMD isn't using AVX512, yet.

jiggawatts 7y ago
Imagine the very near future when AMD starts using TSCM's 5nm process, which has approximately double the transistor density of the current 7nm process used for the EPYC 7002 series. They could go to DDR5, PCIe 5, AVX 512, and still have a transistor budget left over for whatever they like. The 'whatever' is the interesting part. What exactly does a GPU do that a CPU doesn't? Typical GPUs have crazy high memory bandwidths and good latency hiding by using many (thousands) of threads. So if AMD does something like increase the number of memory channels and implement 4-way SMT, they're poised to upset NVIDIA in the HPC space in a big way. Many people would much rather program for a general-purpose processor than the CUDA platform with all of its quirks and limitations...
- chapplap 7y ago
  That's not exactly true once you have to deal with vector extensions like AVX-512. It's quite a pain to write by hand (C intrinsics) and many of the ways to abstract it away end up giving you a GPU-like programming model (eg. Intel ISPC). Plus, this has largely been tried before with Xeon Phi and it didn't end so well. Huge vector units like AVX-512 are mainly useful for workloads that need huge amounts of RAM that you just can't get with a GPU, or for workloads that are very latency sensitive and incompatible with GPU task scheduling because they are in some other CPU-bound code.
  - jiggawatts 7y ago
    > It's quite a pain to write by hand And we all know that autovectorisation is hit-and-miss at best. I wonder if there will be a new C-like language that has portable SIMD-like capabilities in the same sense that "C is a portable assembly language".
    - mmozeiko 7y ago
      There is - Intel SPMD Program Compiler. https://ispc.github.io/ https://ispc.github.io/
      - benibela 7y ago
        But does that work on AMD ?
    - Fronzie 7y ago
      Another one is SyCL: https://www.khronos.org/sycl/ https://www.khronos.org/sycl/ the SIMD part is OpenCL, SyCL provides scheduling/memory transfer on top.
    - DeathArrow 7y ago
      >The first observation is that in modern compilers, the resulting performance from auto-vectorization optimization is still far from the architectural peak performance. https://dl.acm.org/doi/fullHtml/10.1145/3356842 https://dl.acm.org/doi/fullHtml/10.1145/3356842 Maybe we can get get more benefits if we invest more resources in optimizing compilers than in inventing yet another Javascript framework?
  - imtringued 7y ago
    >Huge vector units like AVX-512 are mainly useful for workloads that need huge amounts of RAM that you just can't get with a GPU, or for workloads that are very latency sensitive and incompatible with GPU task scheduling because they are in some other CPU-bound code. There are a lot of tasks that a GPU can do faster than a CPU but it would require batching a large amount of work before you can gain a speedup. EYPC CPUs do not suffer that limitation. If all you have is an array with 4 elements you can straight up run the vector instructions and then immediately switch back to scalar code. Meanwhile with a GPU you probably need at least an array with 10000 elements or more.
- kllrnohj 7y ago
  The memory bandwidth gap between CPUs and GPUs is absolutely ludicrously massive. GPUs already crossed the 1TB/s mark. Epyc Rome is only 204GB/s with DDR4-3200. It's been like this for a decade at least, I don't expect that gap to shrink anytime soon. But realize also the Tesla V100 is still on TSMC 12nm. If Nvidia is moving these they are obviously also going to make 7nm and eventually 5nm variants. Which will also benefit from 2x+ density.
  - jiggawatts 7y ago
    Let's do some maths for my hypothetical EPYC 3: 1) DDR5 is about 2.5x the speed of DDR4: https://www.anandtech.com/show/15699/sk-hynix-ddr5-8400 https://www.anandtech.com/show/15699/sk-hynix-ddr5-8400 2) Dual socket roughly doubles the bandwidth. Measurements are showing something like 300GB/s in practice: https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/6 https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/6 3) AMD could add extra memory channels, a 50% increase is reasonable. 300GB/s x 1.5 for more channels x 2.5 for DDR5 = 1.1 TB/s. Not too shabby! As you said, it would likely be eclipsed by the next-gen NVIDIA accelerator, but... damn, over a terabyte per second for general-purpose compute is just nuts. In principle, AMD could go even higher if they really tried to optimise the platform for this one metric, but server CPUs tend to be "balanced", so I doubt this will happen. One can dream...
    - shaklee3 7y ago
      That's not going to happen. Extra memory channels are very expensive die-wise. Nvidia and AMD achieve these rates with hbm, which has very wide buses (4096 bits) and short traces from stacking. I can't see any way CPU memory will compete until they move to hbm. Keep in mind gddr6 is available in GPUs now, and is faster than ddr5, but much slower than hbm.
      - Dylan16807 7y ago
        The i/o die is 14nm right now. Once that shrinks, it leaves room for more channels. EPYC could use HBM just fine if the advantage is pressing enough.
fluffything 7y ago
A different question is how easy it is to use those FLOPS. The memory bandwidth on a GPU is much higher than on a CPU. Higher FLOP count is useless if the CPU is stalled on memory.
- sudosysgen 7y ago
  However, CPUs have much much better branching performance, and are much easier to fully utilize.
  - diroussel 7y ago
    This is a good point. One place I worked tried to move thier numerical simulations to GGPU, and found they had to move from a recursive algorithm to one more suited to GPU architecture. They did the rewrite, but found the the results were 10% less precise in the convergence on a solution. So the imense parallel nature of a GPU is only useful if your algorithms are the right shape, such as a fixed number of matrix multiplies.
einpoklum 7y ago
That is a problematic metric. You see, you don't buy individual GPUs or CPUs, you buy systems. And typically, you can stick multiple GPUs on the same system (more than CPU)s. There's also the question of what those servers cost, and how many rack units each one takes up etc. And then - it might make more sense to measure power consumption and maintenance costs than up-front price.

jiggawatts 7y ago

Imagine the very near future when AMD starts using TSCM's 5nm process, which has approximately double the transistor density of the current 7nm process used for the EPYC 7002 series. They could go to DDR5, PCIe 5, AVX 512, and still have a transistor budget left over for whatever they like. The 'whatever' is the interesting part. What exactly does a GPU do that a CPU doesn't? Typical GPUs have crazy high memory bandwidths and good latency hiding by using many (thousands) of threads. So if AMD does something like increase the number of memory channels and implement 4-way SMT, they're poised to upset NVIDIA in the HPC space in a big way. Many people would much rather program for a general-purpose processor than the CUDA platform with all of its quirks and limitations...

chapplap 7y ago
That's not exactly true once you have to deal with vector extensions like AVX-512. It's quite a pain to write by hand (C intrinsics) and many of the ways to abstract it away end up giving you a GPU-like programming model (eg. Intel ISPC). Plus, this has largely been tried before with Xeon Phi and it didn't end so well. Huge vector units like AVX-512 are mainly useful for workloads that need huge amounts of RAM that you just can't get with a GPU, or for workloads that are very latency sensitive and incompatible with GPU task scheduling because they are in some other CPU-bound code.
- jiggawatts 7y ago
  > It's quite a pain to write by hand And we all know that autovectorisation is hit-and-miss at best. I wonder if there will be a new C-like language that has portable SIMD-like capabilities in the same sense that "C is a portable assembly language".
  - mmozeiko 7y ago
    There is - Intel SPMD Program Compiler. https://ispc.github.io/ https://ispc.github.io/
    - benibela 7y ago
      But does that work on AMD ?
  - Fronzie 7y ago
    Another one is SyCL: https://www.khronos.org/sycl/ https://www.khronos.org/sycl/ the SIMD part is OpenCL, SyCL provides scheduling/memory transfer on top.
  - DeathArrow 7y ago
    >The first observation is that in modern compilers, the resulting performance from auto-vectorization optimization is still far from the architectural peak performance. https://dl.acm.org/doi/fullHtml/10.1145/3356842 https://dl.acm.org/doi/fullHtml/10.1145/3356842 Maybe we can get get more benefits if we invest more resources in optimizing compilers than in inventing yet another Javascript framework?
- imtringued 7y ago
  >Huge vector units like AVX-512 are mainly useful for workloads that need huge amounts of RAM that you just can't get with a GPU, or for workloads that are very latency sensitive and incompatible with GPU task scheduling because they are in some other CPU-bound code. There are a lot of tasks that a GPU can do faster than a CPU but it would require batching a large amount of work before you can gain a speedup. EYPC CPUs do not suffer that limitation. If all you have is an array with 4 elements you can straight up run the vector instructions and then immediately switch back to scalar code. Meanwhile with a GPU you probably need at least an array with 10000 elements or more.
kllrnohj 7y ago
The memory bandwidth gap between CPUs and GPUs is absolutely ludicrously massive. GPUs already crossed the 1TB/s mark. Epyc Rome is only 204GB/s with DDR4-3200. It's been like this for a decade at least, I don't expect that gap to shrink anytime soon. But realize also the Tesla V100 is still on TSMC 12nm. If Nvidia is moving these they are obviously also going to make 7nm and eventually 5nm variants. Which will also benefit from 2x+ density.
- jiggawatts 7y ago
  Let's do some maths for my hypothetical EPYC 3: 1) DDR5 is about 2.5x the speed of DDR4: https://www.anandtech.com/show/15699/sk-hynix-ddr5-8400 https://www.anandtech.com/show/15699/sk-hynix-ddr5-8400 2) Dual socket roughly doubles the bandwidth. Measurements are showing something like 300GB/s in practice: https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/6 https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/6 3) AMD could add extra memory channels, a 50% increase is reasonable. 300GB/s x 1.5 for more channels x 2.5 for DDR5 = 1.1 TB/s. Not too shabby! As you said, it would likely be eclipsed by the next-gen NVIDIA accelerator, but... damn, over a terabyte per second for general-purpose compute is just nuts. In principle, AMD could go even higher if they really tried to optimise the platform for this one metric, but server CPUs tend to be "balanced", so I doubt this will happen. One can dream...
  - shaklee3 7y ago
    That's not going to happen. Extra memory channels are very expensive die-wise. Nvidia and AMD achieve these rates with hbm, which has very wide buses (4096 bits) and short traces from stacking. I can't see any way CPU memory will compete until they move to hbm. Keep in mind gddr6 is available in GPUs now, and is faster than ddr5, but much slower than hbm.
    - Dylan16807 7y ago
      The i/o die is 14nm right now. Once that shrinks, it leaves room for more channels. EPYC could use HBM just fine if the advantage is pressing enough.

fluffything 7y ago

A different question is how easy it is to use those FLOPS. The memory bandwidth on a GPU is much higher than on a CPU. Higher FLOP count is useless if the CPU is stalled on memory.

sudosysgen 7y ago
However, CPUs have much much better branching performance, and are much easier to fully utilize.
- diroussel 7y ago
  This is a good point. One place I worked tried to move thier numerical simulations to GGPU, and found they had to move from a recursive algorithm to one more suited to GPU architecture. They did the rewrite, but found the the results were 10% less precise in the convergence on a solution. So the imense parallel nature of a GPU is only useful if your algorithms are the right shape, such as a fixed number of matrix multiplies.

einpoklum 7y ago

That is a problematic metric. You see, you don't buy individual GPUs or CPUs, you buy systems. And typically, you can stick multiple GPUs on the same system (more than CPU)s. There's also the question of what those servers cost, and how many rack units each one takes up etc. And then - it might make more sense to measure power consumption and maintenance costs than up-front price.