5 ms·

Skylake is an amazing upgrade, more so than even the Haswell bump. Beyond just the clock-for-clock kind of improvements, AVX512 is a huge win for many vectorize

by boulos 10y ago

Skylake is an amazing upgrade, more so than even the Haswell bump. Beyond just the clock-for-clock kind of improvements, AVX512 is a huge win for many vectorized workloads (see my other comment about waiting nearly 10 years for it...). Linear algebra (or ML if you prefer), rendering, and even string operations (operating on 512-bits per instruction is a win over 256) are all a lot faster.

zbjornson 10y ago
The other fundamental change is that most instructions now have masked variants, so you can apply an operation to only specific elements in a vector based on a mask register. This avoids branch mispredictions, which are a big performance hit in some workloads.
- boulos 10y ago
  Yes, I started syrah (https://github.com/boulos/syrah https://github.com/boulos/syrah) in 2009 precisely because I loved the masking of LRBni and wanted to "use it" even from SSE, AVX and (later) AVX2. Once I played with NEON though, I realized I had screwed up the format for it. Sadly, (because KNL doesn't have nearly the same volume) until Skylake became a real thing, I had no reason to update this. I'm planning on dusting it off now!
  - jdf 10y ago
    Not asking you to reveal any internal plans, but do you think there's any chance that some form of KNL could show up on GCP in the near future? FWIW we're currently using GCP, generally love it, and I'm looking forward to trying out Skylake...
doczoidberg 10y ago
what do I have to consider as a software developer to benefit from these upgrade? Do I need special tools/libraries?
- boulos 10y ago
  For the "clock-for-clock" improvements: nothing. For AVX512, various numerical libraries will be adding support for you over time. However, just as with Haswell and earlier generations, even AVX2 will run better on Skylake.
- aseipp 10y ago
  Simple process improvements that make Skylake faster will just be "there" -- some code will just be faster with no changes! For the numerical, AVX stuff -- it should be mostly automatic for you, if you're already using optimized libraries at the core -- MLK, BLAS, that kind of stuff. They'll be transparently upgraded for you -- ideally -- to take care of these things. They normally check what your CPU is at runtime, and pick the fastest implementation among a few different choices it has. You will need toolchains to support this all, but for the most part that likely won't be a burden unless you want to get your hands dirty and start it yourself -- inevitably, this should all mostly be "pre-canned". Your optimized linear algebra, vector, and math libraries are what will mostly concern themselves with this, not you necessarily. In fact, several of the things already available can probably use these new extensions! I bet if you're using Intel MLK for example, it will probably "magically" get faster on these Skylake machines by using AVX512 automatically. If you want to understand more: you can always go grab an SSE/AVX reference, check your /proc/cpuinfo, and write a few simple things on your own to get a feel. Your toolchain will definitely support it :)
  - martinpw 10y ago
    > I bet if you're using Intel MLK for example, it will probably "magically" get faster on these Skylake machines by using AVX512 automatically. (Aside, I think you mean MKL.) There is a 200MHz clock reduction when running AVX512 instructions. If your code makes heavy use of AVX512 there is of course still a big net win, but I'm curious of the impact with more heterogeneous workloads. We have an app that is a mixture of scalar and vector code. Some, but not all, of the vector code would benefit from 512 bit vectors. But how much does the clock slowdown when running this code bleed over into running the other non-AVX512 code? I guess I'm asking how quickly it clocks down, and how quickly the full clock speed is restored. Worst case it seems you could be running full time at a 200MHz slowdown due to blocks AVX512 instructions scattered throughout the application. Is that a valid concern?

by boulos 10y ago

zbjornson 10y ago

The other fundamental change is that most instructions now have masked variants, so you can apply an operation to only specific elements in a vector based on a mask register. This avoids branch mispredictions, which are a big performance hit in some workloads.

boulos 10y ago
Yes, I started syrah (https://github.com/boulos/syrah https://github.com/boulos/syrah) in 2009 precisely because I loved the masking of LRBni and wanted to "use it" even from SSE, AVX and (later) AVX2. Once I played with NEON though, I realized I had screwed up the format for it. Sadly, (because KNL doesn't have nearly the same volume) until Skylake became a real thing, I had no reason to update this. I'm planning on dusting it off now!
- jdf 10y ago
  Not asking you to reveal any internal plans, but do you think there's any chance that some form of KNL could show up on GCP in the near future? FWIW we're currently using GCP, generally love it, and I'm looking forward to trying out Skylake...

doczoidberg 10y ago

what do I have to consider as a software developer to benefit from these upgrade? Do I need special tools/libraries?

boulos 10y ago
For the "clock-for-clock" improvements: nothing. For AVX512, various numerical libraries will be adding support for you over time. However, just as with Haswell and earlier generations, even AVX2 will run better on Skylake.
aseipp 10y ago
Simple process improvements that make Skylake faster will just be "there" -- some code will just be faster with no changes! For the numerical, AVX stuff -- it should be mostly automatic for you, if you're already using optimized libraries at the core -- MLK, BLAS, that kind of stuff. They'll be transparently upgraded for you -- ideally -- to take care of these things. They normally check what your CPU is at runtime, and pick the fastest implementation among a few different choices it has. You will need toolchains to support this all, but for the most part that likely won't be a burden unless you want to get your hands dirty and start it yourself -- inevitably, this should all mostly be "pre-canned". Your optimized linear algebra, vector, and math libraries are what will mostly concern themselves with this, not you necessarily. In fact, several of the things already available can probably use these new extensions! I bet if you're using Intel MLK for example, it will probably "magically" get faster on these Skylake machines by using AVX512 automatically. If you want to understand more: you can always go grab an SSE/AVX reference, check your /proc/cpuinfo, and write a few simple things on your own to get a feel. Your toolchain will definitely support it :)
- martinpw 10y ago
  > I bet if you're using Intel MLK for example, it will probably "magically" get faster on these Skylake machines by using AVX512 automatically. (Aside, I think you mean MKL.) There is a 200MHz clock reduction when running AVX512 instructions. If your code makes heavy use of AVX512 there is of course still a big net win, but I'm curious of the impact with more heterogeneous workloads. We have an app that is a mixture of scalar and vector code. Some, but not all, of the vector code would benefit from 512 bit vectors. But how much does the clock slowdown when running this code bleed over into running the other non-AVX512 code? I guess I'm asking how quickly it clocks down, and how quickly the full clock speed is restored. Worst case it seems you could be running full time at a 200MHz slowdown due to blocks AVX512 instructions scattered throughout the application. Is that a valid concern?