The story of ISPC: origins (part 1)
Whoever wrote ISPC &quot;gets it&quot;, that SIMD lanes can be treated as if they were threads. You almost have to program in OpenCL or CUDA before you realize that SIMD code can be like normal serial code (with just a few, really really weird performance quirks).<p>I haven&#x27;t really been able to use ISPC myself yet, but its on my to-do list. I&#x27;ve found that a lot of code fails to run well on a GPU and still needs a normal CPU for computation... but some SIMD bits here and there can really benefit from a higher-level language (rather that writing in intrinsics or relying on auto-vectorizers).<p>GPUs are still very far away from the CPU. You gotta push your data to RAM, then over a PCIe lanes... and spend many microseconds to miliseconds pushing the data to-and-from the GPU. While SIMD on a CPU benefits from L1 cache locality.<p>Intrinsics definitely work, but are hard to program. Auto-vectorizers don&#x27;t really structure the program correctly... and require a ton of study to use correctly.<p>ISPC seems like the real way to get well-&quot;threaded&quot; SIMD code written productively for CPUs. It hides things behind relatively easy to understand abstractions and is the best &#x27;CUDA &#x2F; OpenCL for the CPU&#x27; I&#x27;ve found so far.<p>---------<p>Why not use CUDA? Well, CUDA doesn&#x27;t share L1 cache with my CPU cores. That&#x27;s why. You can&#x27;t beat AVX in terms of latency. CUDA &#x2F; NVidia GPUs are way faster, but you have to spend a LOT of time transferring data before CUDA code even begins to compute.<p>In contrast, ispc compiles to a .o that links into your standard C or C++ code you&#x27;ve been writing.