6 ms·

> The Teslas have good double-precision performance - but they are priced waaaay higher than the consumer cards. Yup - the Tesla V100 is 7 TFLOPs of double-pre

> The Teslas have good double-precision performance - but they are priced waaaay higher than the consumer cards. Yup - the Tesla V100 is 7 TFLOPs of double-precision at around ~$9000 A huge split between consumer & HPC happened in the aftermath of the Fermi (2010) architecture. Fermi was really bad in the consumer space from all the wasted die spent on unused double-precision. It was late, hot, and loud. And barely even faster than the competition. With Maxwell Nvidia basically removed all the FP64 support from the architecture itself ( https://www.anandtech.com/show/9059/the-nvidia-geforce-gtx-titan-x-review/2 https://www.anandtech.com/show/9059/the-nvidia-geforce-gtx-t... - native FP64 rate is 1/32'd the FP32 rate) - the result was a huge boost to gaming performance. But it also meant that HPC users who want double-precision had to use Tesla cards. The actual architectures between GeForce & Tesla are different now, it's not "just" a lockout anymore.

Robotbeat 7y ago
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?
- 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.

Robotbeat 7y ago

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