On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:
>
> I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)

Other than the execution runtime, one other very important problem with DMD that wasn't refered is that is only support x86 and x86_64. LDC and GDC support LLVM's and GCC's architectures respectively.

On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote:
> On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
>>
>> target.obj: target.c include1.h include2.h cc.exe
>>     cc target.c
>>
>> and you either have to pray that you have kept the list of .h files that are mentioned inside target.c and other .h files referenced recursively from within these .h files etc. I listed the compiler as a dependency too, and I should really have a pseudo-target somehow that depends on the nature of the command line because changing the command line affects the generated code. If you have an automaking compiler that will generate the list of .h files then that’s so, so much safer.
>
> First of all, If we are talking about C files, D can import and compile them so you don't even need a Makefile! Now, if you need to compile C++ files and then either link or create a library (and link with it from the D project), then you can just run Dub in the end of the job in your make file! You can then have a variable called `DUB_FLAGS` in your Makefile and this is where the arguments that will be passed for the Dub will be. Will this be good enough for you?

If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work!

On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:
>
> If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work!

Of course, DMD uses it's own custom backend so it's only fair to not expect for it to have the same runtime performance and optimizations as the other two compilers than use LLVM and GCC. If you only use x86_64, DMD will be amazing for your debug cycles!

On Sunday, 18 June 2023 at 21:51:14 UTC, Jonathan M Davis wrote:
> On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn wrote:
>> I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)
>
> In general, dmd is fantastic for its fast compilation speed. So, it works really well for developing whatever software you're working on (whereas ldc and gdc are typically going to be slower at compiling). And depending on what you're doing, the code is plenty fast. However, if you want to maximize the efficiency of your code, then you definitely want to be building the binaries that you actually use or release with ldc or gdc.
>
> - Jonathan M Davis

Good point. I’m used to slow compilers on fast machines and compiling gives me an excuse for more coffee and possibly fruity buns. I’m incredibly impressed with LDC, GDC slightly less so, as it sometimes calls runtime library routines where Ldc doesn’t. Like in things to do with arrays, for one example.

I hate calls to runtime library routines unless they are really substantial, mind you many calls to a modest-sized routine can get you a hotter cache, and even micro-op cache, and keep the whole code size down so as to improve cache overload or even pollution.

On Monday, 19 June 2023 at 16:24:03 UTC, rempas wrote:
> On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:
>>
>> If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work!
>
> Of course, DMD uses it's own custom backend so it's only fair to not expect for it to have the same runtime performance and optimizations as the other two compilers than use LLVM and GCC. If you only use x86_64, DMD will be amazing for your debug cycles!

I’ve never used DMD. I don’t support that it will run on Aarch64. I’m running ldc on an ARM M2 Mac OSX. Also on x86-64 VMs at Godbolt.org but I must get access to an x86-64 box myself.

On 6/20/23 08:09, Cecil Ward wrote:

> I’m used to slow compilers on fast machines and compiling
> gives me an excuse for more coffee and possibly fruity buns.

Yes, all of us in past projects accepted C++'s slowness. We did get coffee, etc. One of my current colleagues regularly plays solitaire when waiting for C++ compilations. Not only it's not a professional sight, but C++ is proving to be a professional mistake.

Nobody should suffer from such context switches. I have a hunch, without any backing research data, that C++'s contribution to humanity may be net negative.

D is nothing like that: My turnaround is a few seconds: Write, compile, run, see the effect... I use only dmd partly because of laziness: it just works. Although I take full advantage D's low level powers, my programs have mostly been I/O bound with huge files, so dmd's less-than ideal optimization powers are hidden because most threads are waiting for file system I/O.

Aside: std.parallelism and std.concurrency have been very helpful.

Ali

On Tuesday, 20 June 2023 at 17:56:27 UTC, Ali Çehreli wrote:
> On 6/20/23 08:09, Cecil Ward wrote:
>
> > I’m used to slow compilers on fast machines and compiling
> > gives me an excuse for more coffee and possibly fruity buns.
>
> Yes, all of us in past projects accepted C++'s slowness. We did get coffee, etc. One of my current colleagues regularly plays solitaire when waiting for C++ compilations. Not only it's not a professional sight, but C++ is proving to be a professional mistake.
>
> Nobody should suffer from such context switches. I have a hunch, without any backing research data, that C++'s contribution to humanity may be net negative.
>
> D is nothing like that: My turnaround is a few seconds: Write, compile, run, see the effect... I use only dmd partly because of laziness: it just works. Although I take full advantage D's low level powers, my programs have mostly been I/O bound with huge files, so dmd's less-than ideal optimization powers are hidden because most threads are waiting for file system I/O.
>
> Aside: std.parallelism and std.concurrency have been very helpful.
>
> Ali

In the 1980s on our VAX 11/750, compile jobs were batch jobs placed in a queue. Half hour waits were not unknown. A build of the new o/s we were working on took around 40 mins on a 33 MHz 386 Dell PC (later a 486!) iirc. So time for patisserie even. But in oractice you simply got on with other jobs, like writing new code that was not yet integrated, code reviews, all sorts of things.