4 ms·

SIMD is generally written by hand in assembly. Libjpegturbo or ffmpeg have a lot of handwritten SIMD for various platforms. Sometimes you have to use compiler

SIMD is generally written by hand in assembly. Libjpegturbo or ffmpeg have a lot of handwritten SIMD for various platforms. Sometimes you have to use compiler intrinsics to do parts of vectorization because of odd issues with the platform like differences in various chips. Parallelization is a different matter, but you can combine the two.

dragontamer 5y ago
> SIMD is generally written by hand in assembly. Libjpegturbo or ffmpeg have a lot of handwritten SIMD for various platforms. Note that CPU-SIMD written in this manner is a subdiscipline called SWAR: SIMD-within-a-register. When we compare/contrast SWAR-SIMD (such as SSE / AVX / NEON / Altivec, etc. etc.) vs GPU-SIMD (NVidia CUDA, AMD ROCm), we notice that the two styles are extremely similar at the assembly language level (!!!). There's a few differences that lead to major performance contrasts, but when an AMD Vega-GPU performs the "V_ADD_CO_U32" assembly instruction, its very similar to the Intel-AVX512 "vpaddd" instruction (except Vega-GPU is over 64x32-bit, while AVX512 is just over 16x32-bit). So at the assembly language level, I assert that GPU-SIMD and CPU-SIMD+SWAR are more similar than most people think. ------------ The primary difference is in the expectation in what the compiler can or can't do. In particular: CPU-SIMD+SWAR programmers have been programming in either assembly language (back in MMX-days) or compiler-intrinsics because... lets be frank... the compiler sucks still. Autovectorization sucks so much that our only choice is to dip down into intrinsics and/or assembly language directly. In contrast, GPU-SIMD programmers have created more-and-more elaborate compilers / transformations to support a greater variety of programming structures. Its possible to program in a SIMD-manner today using a "high level language" like CUDA / OpenCL. ------- Based on my experiments in the GPU-programming world, I'm convinced that the OpenMP committee "gets" it. They too seem to have seen the benefits of a higher-level abstractions that CUDA / OpenCL offers, and are beginning to translate those abstractions into OpenMP. The #pragma omp simd constructs are marching in the right direction (albeit many years behind CUDA/OpenCL, but... they seem to be at least going in the right direction). https://pages.tacc.utexas.edu/~eijkhout/pcse/html/omp-simd.html https://pages.tacc.utexas.edu/~eijkhout/pcse/html/omp-simd.h... ------- Not all of us are willing to use intrinsics / raw assembly language for the rest of our days. :-) Some of us are looking for ways to bring forth those performance benefits of SIMD into a higher-level language. There will always be a place for intrinsics / raw assembly language, but we definitely prefer for "most" code to be written in a more easily understood manner.

dragontamer 5y ago

> SIMD is generally written by hand in assembly. Libjpegturbo or ffmpeg have a lot of handwritten SIMD for various platforms. Note that CPU-SIMD written in this manner is a subdiscipline called SWAR: SIMD-within-a-register. When we compare/contrast SWAR-SIMD (such as SSE / AVX / NEON / Altivec, etc. etc.) vs GPU-SIMD (NVidia CUDA, AMD ROCm), we notice that the two styles are extremely similar at the assembly language level (!!!). There's a few differences that lead to major performance contrasts, but when an AMD Vega-GPU performs the "V_ADD_CO_U32" assembly instruction, its very similar to the Intel-AVX512 "vpaddd" instruction (except Vega-GPU is over 64x32-bit, while AVX512 is just over 16x32-bit). So at the assembly language level, I assert that GPU-SIMD and CPU-SIMD+SWAR are more similar than most people think. ------------ The primary difference is in the expectation in what the compiler can or can't do. In particular: CPU-SIMD+SWAR programmers have been programming in either assembly language (back in MMX-days) or compiler-intrinsics because... lets be frank... the compiler sucks still. Autovectorization sucks so much that our only choice is to dip down into intrinsics and/or assembly language directly. In contrast, GPU-SIMD programmers have created more-and-more elaborate compilers / transformations to support a greater variety of programming structures. Its possible to program in a SIMD-manner today using a "high level language" like CUDA / OpenCL. ------- Based on my experiments in the GPU-programming world, I'm convinced that the OpenMP committee "gets" it. They too seem to have seen the benefits of a higher-level abstractions that CUDA / OpenCL offers, and are beginning to translate those abstractions into OpenMP. The #pragma omp simd constructs are marching in the right direction (albeit many years behind CUDA/OpenCL, but... they seem to be at least going in the right direction). https://pages.tacc.utexas.edu/~eijkhout/pcse/html/omp-simd.html https://pages.tacc.utexas.edu/~eijkhout/pcse/html/omp-simd.h... ------- Not all of us are willing to use intrinsics / raw assembly language for the rest of our days. :-) Some of us are looking for ways to bring forth those performance benefits of SIMD into a higher-level language. There will always be a place for intrinsics / raw assembly language, but we definitely prefer for "most" code to be written in a more easily understood manner.