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