4 ms·

> They are planning a knight's landing Xeon Phi with 72 out of order cores, each with 4 hyperthreads and two 512 bit SIMD units... I think Intel is probably pl

by vardump 11y ago

> They are planning a knight's landing Xeon Phi with 72 out of order cores, each with 4 hyperthreads and two 512 bit SIMD units... I think Intel is probably planning to unify CPU and GPU. Intel has been bringing GPU-like features to CPUs like very wide SIMD, gather (vectorized memory load), etc. Just scatter (vectorized store), a 2D-optimized cache controller (for trilinear filtering and hardware swizzling) and fast HBM memory are missing from the latest Skylake CPUs. Otherwise current crop of CPUs can pretty much be a GPU. An 18 core 2.3 GHz Haswell Xeon has 1.3 TFLOPS peak. > CPUs are WAY faster than most people realize but the way current software is written leaves anywhere from 10x-100x the performance on the table. Yeah, just a single Haswell core can do 32 (FMA) flops per clock cycle. Other then specialty optimized software, it might see a flop or two every few cycles while being idle a lot. On the other hand, most software can't be 10-100x faster. 2-10x is pretty common, though. Compilers are still somewhat bad at using SIMD cleverly. Sometimes they do surprise. > Right now the best option is ISPC, Intel's compiler. Right now the best option is to still to use assembler or intrinsics (when compiler does ok job at instruction scheduling), at least if you need serial performance in "normal" applications. ISPC is of course nice for very parallel problems.

yvdriess 11y ago
Intel's icc (and even gcc) got really good at vectorization these last few years. It's rare when I see some code that the vectorization-report says is not worth vectorizing that actually is. Last week, I got better results by leaving out the intrinsics. The code-reorganization you do to put in vec intrinsics will definitely make the compiler's vectorization-optimization trigger. Just keep an eye on the compiler's vec reports :)
- slizard 11y ago
  That may be true for simple operations on aligned buffers, and nice regular computation in general. Anything slightly complex will throw off the compiler and result in suboptimal performance in the best case, none or stupid vectorization the worst (and quite common) case. How do I know? We have some experience with vectorization in the team I work in (www.gromacs.org), our code has support for at about 10-12 SIMD instruction sets ;)
- vardump 11y ago
  ICC and GCC produce pretty nice scalar code, but their vectorization abilities are far from perfect. Compiler vectorization tends to also be less stable, slightest changes can make the compiler to drop the optimizations in a later build. It might not ideal to use intrinsics, but that's how you get predictable performance.

by vardump 11y ago

yvdriess 11y ago

Intel's icc (and even gcc) got really good at vectorization these last few years. It's rare when I see some code that the vectorization-report says is not worth vectorizing that actually is. Last week, I got better results by leaving out the intrinsics. The code-reorganization you do to put in vec intrinsics will definitely make the compiler's vectorization-optimization trigger. Just keep an eye on the compiler's vec reports :)

slizard 11y ago
That may be true for simple operations on aligned buffers, and nice regular computation in general. Anything slightly complex will throw off the compiler and result in suboptimal performance in the best case, none or stupid vectorization the worst (and quite common) case. How do I know? We have some experience with vectorization in the team I work in (www.gromacs.org), our code has support for at about 10-12 SIMD instruction sets ;)
vardump 11y ago
ICC and GCC produce pretty nice scalar code, but their vectorization abilities are far from perfect. Compiler vectorization tends to also be less stable, slightest changes can make the compiler to drop the optimizations in a later build. It might not ideal to use intrinsics, but that's how you get predictable performance.