Vectorization Virtual Workshop
Hmm. Its a good resource, but I&#x27;m pretty bearish on autovectorization in this manner.<p>After trying OpenCL &#x2F; CUDA &#x2F; ROCm style programming, its clear that writing explicitly parallel code is in fact easier than expected (albeit with a ton of study involved... but I bet anyone can learn it if they put their mind to it).<p>If CPU-SIMD is really needed for some reason, I expect that the languages that will be most convenient are explicitly-parallel systems like OpenMP or ISPC.<p>In particular, look at these restrictions: <a href="https:&#x2F;&#x2F;cvw.cac.cornell.edu&#x2F;vector&#x2F;coding_vectorizable" rel="nofollow">https:&#x2F;&#x2F;cvw.cac.cornell.edu&#x2F;vector&#x2F;coding_vectorizable</a><p>&gt; The loop must be countable at runtime.<p>&gt; There should be a single control flow within the loop.<p>&gt; The loop should not contain function calls.<p>These three restrictions are extremely restrictive!! CUDA &#x2F; OpenCL &#x2F; ROCm allow these constructs. Control flow may have terrible performance in CUDA &#x2F; OpenCL, but its allowed (because its convenient. If the programmer can&#x27;t think of any way to solve a problem aside from a few more if-statements &#x2F; switch-statements, then we should let them even if its inefficient).<p>That&#x27;s the thing. We know that SIMD-machines and languages designed for SIMD-machines can have dynamic loop counts and more than one if-statement (albeit with a branch divergence penalty). We also find it extremely convenient to decompose our problems into functions and sub-functions.<p>---------------------<p>OpenMP in contrast, looks like its learning from OpenCL &#x2F; CUDA. The #omp simd parallel for construct is moving closer-and-closer to CUDA&#x2F;OpenCL parity, allowing for convenient &quot;if&quot; statements and &quot;dynamic loop counts&quot;.<p>CPU-SIMD is here to stay, and I think learning how to use it is very important. But autovectorization from the compiler (without any programmer assist) looks like a dead end. The compiler gets a LOT of help when the programmer states things in terms of &quot;threadIdx.x&quot;, and other explicitly SIMD variable concepts.<p>Besides, if the programmer is forced to learn all of these obscure rules &#x2F; obscure programming methods (countable loops &#x2F; only  one control flow within the loop &#x2F; etc. etc.), you&#x27;re pretty much learning a sublanguage without any syntax to indicate that you&#x27;ve switched languages. Discoverability is really bad.<p>If I instead say &quot;#pragma omp parallel simd for&quot; before using some obscure OpenMP features, any C&#x2F;C++ programmer these days will notice that something is weird and search on those terms before reading the rest of the for-loop.<p>A for-loop written in &quot;autovectorized&quot; style has no such indicator, no such &quot;discoverability&quot; to teach non-SIMD programmers what the hell is going on.<p>---------<p>Kind of a shame, because this resource is excellently written and still worth a read IMO. Even if I think the tech is a bit of a dead-end.