Fixing C's Biggest Mistake

Bruce Carneal bcarneal at gmail.com
Sat Dec 24 21:27:29 UTC 2022


On Saturday, 24 December 2022 at 20:52:53 UTC, Iain Buclaw wrote:
> On Saturday, 24 December 2022 at 09:54:41 UTC, Siarhei 
> Siamashka wrote:
>> On Saturday, 24 December 2022 at 09:30:15 UTC, RTM wrote:
>>> On Saturday, 24 December 2022 at 09:23:10 UTC, GrimMaple 
>>> wrote:
>>>> I wouldn't bring Remedy as a success story considering they 
>>>> ditched D right after Ethan left.
>>>
>>> I disagree. Without core.SIMD, there would be nothing to 
>>> ditch.
>>
>> Is or was anyone other than Remedy using `core.simd`? There 
>> had to be a very good reason to design it in a way that is 
>> incompatible with the de-facto standard GCC intrinsics and 
>> vector extensions.
>
> GDC and LDC provide implementations for the generic intrinsics 
> - in 
> [gcc.simd](https://github.com/gcc-mirror/gcc/blob/master/libphobos/libdruntime/gcc/simd.d) and [ldc.simd](https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/simd.di) respectively though.  I can only think of the intel intrinsics library that would use the non-portable `__simd` functions for the sake of DMD support.

Yeah.  Auto vec and ldc.simd/gcc.simd + their intrinsics cover 
it, for me anyway.  Choosing to use the DMD back-end for 
performance critical SIMD work would be peculiar.

Manual unrolling with static foreach within vLen target 
introspected library functions can help you avoid some 
intrinsics, if that is your goal, *but* you'll then be on the 
hook for checking that the optimizer "does the right thing".  
Tradeoffs...

Dlang has a pretty good story wrt data parallel programming 
already and it's getting better (thanks Iain, Nic, Guillaume, 
Manu, ...).



More information about the Digitalmars-d mailing list