auto vectorization notes

[Crayo List]

On Saturday, 28 March 2020 at 06:56:14 UTC, Bruce Carneal wrote:
> On Saturday, 28 March 2020 at 05:21:14 UTC, Crayo List wrote:
>> On Monday, 23 March 2020 at 18:52:16 UTC, Bruce Carneal wrote:
>>> [snip]
>>> (on the downside you have to guard against compiler code-gen 
>>> performance regressions)
>>>
>>
>> auto vectorization is bad because you never know if your code 
>> will get vectorized next time you make some change to it and 
>> recompile.
>> Just use : https://ispc.github.io/
>
> Yes, that's a downside, you have to measure your performance 
> sensitive code if you change it *or* change compilers or 
> targets.
>
> Explicit SIMD code, ispc or other, isn't as readable or 
> composable or vanilla portable but it certainly is performance 
> predictable.

This is not true! The idea of ispc is to write portable code that 
will
vectorize predictably based on the target CPU. The object 
file/binary is not portable,
if that is what you meant.
Also, I find it readable.

> I find SIMT code readability better than SIMD but a little 
> worse than auto-vectorizable kernels.  Hugely better 
> performance though for less effort than SIMD if your platform 
> supports it.

Again I don't think this is true. Unless I am misunderstanding 
you, SIMT and SIMD
are not mutually exclusive and if you need performance then you 
must use both.
Also based on the workload and processor SIMD may be much more 
effective than SIMT.