5 ms·

Differ t workloads will be if it in different ways from the trade offs. I do t imagine many applications will miss AVX 512.

jcoffland 10y ago
It's actually quite difficult to use AVX512 and have it pay off significantly unless you design something to specifically take advantage of it.
- m_mueller 10y ago
  Exactly. IMO doing GPGPU is actually easier than porting code to use vectorisation, since GPU cores are quite a bit more capable (allow branching/context switches, just with a performance penalty) than the CPUs vector units (vector code AFAIK completely breaks if you try to do an early return on one unit). I'm waiting for the day when the CPU designers learn from GPU and just give us full OpenMP kernel support, such that you can use both multicore and vectorization by just scattering the OpenMP kernel call, including branching and early returns inside the kernels. I actually think that the higher core Xeons would still be quite competitive with GPUs if that was the case, but as it stands even the Intel MICs are a pain to program effectively. Doing this all with OpenMP is IMO just not good solution, it's very hard figuring out where things goes wrong.
  - jcoffland 10y ago
    Have you looked into Xeon Phi? They have up to 288 threads. With a 256 thread Xeon we got good speed ups using up to 128 threads with Folding@home's latest GROMACS core (0xa7). With higher thread counts it failed to improve. In the long-run massively parallel CPUs could outpace GPUs precisely because of their flexibility. Note that the 0xa7 core also uses 256 AVX. That's multiple CPU threads and vector instructions.
    - m_mueller 10y ago
      I haven't tried MICs personally, but AFAIK you need vectorization to match current Pascal generation GPU performance with Knight's landing -> which is where my comment applies. I don't doubt that you can get good speedups when this applies to your code already, but if you start from naive CPU code you'll have a lot of work to do, which IMO is similar to the work needed to port to GPGPU.
      - jcoffland 10y ago
        That is true. CPUs are catching up to GPUs in some ways. Intel is doing its best to take this market from NVidia. The future will tell.
  - m_mueller 10y ago
    > just give us full OpenMP kernel support, such that you can use both multicore and vectorization by just scattering the OpenMP oops. s/OpenMP/OpenCL
  - gcp 10y ago
    Note that AVX512 actually addresses many of the issues that made SIMT code so inefficient on CPUs. It's not just widening the vectors, but also adding predication/masking etc. I do fully agree that SIMT is a much easier programming model than SIMD.
    - m_mueller 10y ago
      Interesting, TIL. How good is the support for OpenCL on AVX512 processors?
      - gcp 10y ago
        So far that's only Knights Landing and friends, but they do seem well supported.
gpderetta 10y ago
Skylake doesn't have AVX512. Still those two 256 bit ALUs do take a lot of space an at least partially explain the size difference.
JustSomeNobody 10y ago
OT, but did your 'n' key fall off?

jcoffland 10y ago

It's actually quite difficult to use AVX512 and have it pay off significantly unless you design something to specifically take advantage of it.

m_mueller 10y ago
Exactly. IMO doing GPGPU is actually easier than porting code to use vectorisation, since GPU cores are quite a bit more capable (allow branching/context switches, just with a performance penalty) than the CPUs vector units (vector code AFAIK completely breaks if you try to do an early return on one unit). I'm waiting for the day when the CPU designers learn from GPU and just give us full OpenMP kernel support, such that you can use both multicore and vectorization by just scattering the OpenMP kernel call, including branching and early returns inside the kernels. I actually think that the higher core Xeons would still be quite competitive with GPUs if that was the case, but as it stands even the Intel MICs are a pain to program effectively. Doing this all with OpenMP is IMO just not good solution, it's very hard figuring out where things goes wrong.
- jcoffland 10y ago
  Have you looked into Xeon Phi? They have up to 288 threads. With a 256 thread Xeon we got good speed ups using up to 128 threads with Folding@home's latest GROMACS core (0xa7). With higher thread counts it failed to improve. In the long-run massively parallel CPUs could outpace GPUs precisely because of their flexibility. Note that the 0xa7 core also uses 256 AVX. That's multiple CPU threads and vector instructions.
  - m_mueller 10y ago
    I haven't tried MICs personally, but AFAIK you need vectorization to match current Pascal generation GPU performance with Knight's landing -> which is where my comment applies. I don't doubt that you can get good speedups when this applies to your code already, but if you start from naive CPU code you'll have a lot of work to do, which IMO is similar to the work needed to port to GPGPU.
    - jcoffland 10y ago
      That is true. CPUs are catching up to GPUs in some ways. Intel is doing its best to take this market from NVidia. The future will tell.
- m_mueller 10y ago
  > just give us full OpenMP kernel support, such that you can use both multicore and vectorization by just scattering the OpenMP oops. s/OpenMP/OpenCL
- gcp 10y ago
  Note that AVX512 actually addresses many of the issues that made SIMT code so inefficient on CPUs. It's not just widening the vectors, but also adding predication/masking etc. I do fully agree that SIMT is a much easier programming model than SIMD.
  - m_mueller 10y ago
    Interesting, TIL. How good is the support for OpenCL on AVX512 processors?
    - gcp 10y ago
      So far that's only Knights Landing and friends, but they do seem well supported.

gpderetta 10y ago

Skylake doesn't have AVX512. Still those two 256 bit ALUs do take a lot of space an at least partially explain the size difference.

JustSomeNobody 10y ago

OT, but did your 'n' key fall off?