Fixing C's Biggest Mistake (page 10)

On Saturday, 24 December 2022 at 09:20:26 UTC, RTM wrote: > On Saturday, 24 December 2022 at 08:57:45 UTC, GrimMaple wrote: >> It's the fact that you keep introducing half-baked solutions so nobody understands what the heck to focus on, and what to fix. > > Sometimes it works. SIMD features were added that way, and it brought D into Remedy’s games. I wouldn't bring Remedy as a success story considering they ditched D right after Ethan left.

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.

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.

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 and ldc.simd 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.

December 24, 2022

Re: Fixing C's Biggest Mistake

Posted by Bruce Carneal
in reply to Iain Buclaw

Permalink

Bruce Carneal

Posted in reply to Iain Buclaw

Permalink

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.

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, ...).

On Saturday, 24 December 2022 at 09:20:26 UTC, RTM wrote: > > .. > To the topic. > ImportC is good thing. There are lots and lots of libraries written in C. > Extending C syntax is definitely not, it’s a time wasted. No one can beat Herb Sutter (CPPfront). Please don't compare ImportC to cppfront,as you just made the case for importC much stronger ;-) i.e.cppFront will happily compile this (even though no such function exists..anywhere): main: () -> int = { printMyMessage(); } it's only when you try to compile the file cppfront outputs, using a 'proper' compiler, will you learn that no such function exists.

On Sunday, 25 December 2022 at 20:34:25 UTC, bachmeier wrote: > > To be honest, I spend hours learning every time I write C code. And it's not the fun kind of learning. It's time spent debugging uninteresting things because the language is an abomination. C was designed to compete with assembly. I'm unaware of any other programming language that has been more successful in doing just that. The problems you mention, are the price one must pay, to use C. It's also why it so hard to create a 'better' C. Cause you can't.

Forums