3 ms·

Do you still need to use vector instructions on KNL to get top performance? If so then forgot about "familiarity" when rewriting.

by llukas 10y ago

m_mueller 10y ago
This is exactly the biggest downfall of the Larrabee/Phi programming model. The claim that you can just deploy your CPU code is simply wrong if vectorization isn't taken into account. I'd argue it's worse than porting it to GPU if you start with code that's "naively" parallelized for CPU with OpenMP statements without unrolling/vector intrinsics. The reason is that the actual kernel code can stay the same for CUDA, or it can be relatively easily transformed (something I'm working on [1]) - just take whatever was inside your OpenMP loops and move it into a CUDA kernel. Meanwhile for Phi I'd have to now care about two levels of parallelism instead of just one (multicore/vector). The entire reason why GPU has been so successful, is that its performance is relatively predictable compared to x86 cores because of its much simpler architecture - and putting hundreds of them on a single chip doesn't change that. Granted, there are applications that will perform better on KNL than GPU (I expect), because it has a somewhat greater degree of freedom (although the bandwidth you get when actually using that freedom will be a deciding factor on whether it's actually worth it over the latest CPUs in those cases). [1] https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran
elihu 10y ago
That's just because KNL is the only chip available right now with AVX-512; presumably this will be available on other CPUs in the future.
gbrown_ 10y ago
Do you still need to use vector instructions on KNL to get top performance? Yes, but this is also the case for regular Xeons. If so then forgot about "familiarity" when rewriting. When I say "familiarity" I'm referring to tooling in things like compilers and debuggers as well as just the instruction set.
- gnufx 10y ago
  Right. The only thing that looks particularly different (compared with the typical HPC node intended for workhorse vectorized code) about KNL on paper is the memory system, and possibly integrated interconnect. Given the usual library support, I don't see why there should be significant re-writing to be done, any more than for other AVX transitions (unless you're developing BLAS etc.).

Do you still need to use vector instructions on KNL to get top performance? If so then forgot about "familiarity" when rewriting.

by llukas 10y ago

Do you still need to use vector instructions on KNL to get top performance? If so then forgot about "familiarity" when rewriting.

m_mueller 10y ago

This is exactly the biggest downfall of the Larrabee/Phi programming model. The claim that you can just deploy your CPU code is simply wrong if vectorization isn't taken into account. I'd argue it's worse than porting it to GPU if you start with code that's "naively" parallelized for CPU with OpenMP statements without unrolling/vector intrinsics. The reason is that the actual kernel code can stay the same for CUDA, or it can be relatively easily transformed (something I'm working on [1]) - just take whatever was inside your OpenMP loops and move it into a CUDA kernel. Meanwhile for Phi I'd have to now care about two levels of parallelism instead of just one (multicore/vector). The entire reason why GPU has been so successful, is that its performance is relatively predictable compared to x86 cores because of its much simpler architecture - and putting hundreds of them on a single chip doesn't change that. Granted, there are applications that will perform better on KNL than GPU (I expect), because it has a somewhat greater degree of freedom (although the bandwidth you get when actually using that freedom will be a deciding factor on whether it's actually worth it over the latest CPUs in those cases). [1] https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran

elihu 10y ago

That's just because KNL is the only chip available right now with AVX-512; presumably this will be available on other CPUs in the future.

gbrown_ 10y ago

Do you still need to use vector instructions on KNL to get top performance? Yes, but this is also the case for regular Xeons. If so then forgot about "familiarity" when rewriting. When I say "familiarity" I'm referring to tooling in things like compilers and debuggers as well as just the instruction set.

gnufx 10y ago
Right. The only thing that looks particularly different (compared with the typical HPC node intended for workhorse vectorized code) about KNL on paper is the memory system, and possibly integrated interconnect. Given the usual library support, I don't see why there should be significant re-writing to be done, any more than for other AVX transitions (unless you're developing BLAS etc.).