[Moving this to separate thread because it's tangential to DIP 1031 discussion.]

On Sat, Feb 15, 2020 at 03:59:39PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/15/2020 9:58 AM, jxel wrote:
> > how poor quality the backend code is.
> 
> Baloney.
> 
> It's written in an older style, sure, but it's remarkably bug free considering how complex it is. The complexity is a result of the fiendishly complex x86 instructions set.
> 
> The proof of its quality is it has successfully been extended from a purely 16 bit generator to 32 and extended again to 64 bit, and has been extended to support multiple ABIs and object file formats.
> 
> The DFA optimizer has also proven to be fast and very robust.

Unfortunately, the GDC and LDC optimizers consistently produce code that outperforms code generated by the DMD backend by 20-30%, sometimes as high as 40% for CPU-intensive code. DMD also tends to have more codegen bugs when run with -O -inline (which, ironically, still produces inferior code to what LDC/GDC produces with -O).

I'm sure, given enough time and effort, you could bring it to par, but after >5 years of waiting, I've essentially given up on the DMD backend for performance-sensitive code.  I now use LDC for my larger projects, and would probably start new projects on LDC rather than DMD.

LDC can also cross-compile to Windows from Linux, which allows me the very convenient setup of a single build script that builds both Linux and Windows executables simultaneously.  With DMD I need a VM or at least Wine (with its very slow and resource-intensive startup times) to be able to do this. And LDC can target a *lot* more architectures than x86 on Linux/Windows, such as WebAssembly, Android, etc.. Again, DMD loses out here.

Of course, DMD is still very fast at compiling and useful for smaller utilities and script-like programs where performance isn't critical, or for running unittests for isolated modules during development due to fast turnaround times. But codegen quality is definitely not among the reasons I still use DMD.


T

-- 
Computers shouldn't beep through the keyhole.

On Sunday, 16 February 2020 at 00:16:24 UTC, H. S. Teoh wrote:
> [Moving this to separate thread because it's tangential to DIP 1031 discussion.]
>
> On Sat, Feb 15, 2020 at 03:59:39PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 2/15/2020 9:58 AM, jxel wrote:
>> > how poor quality the backend code is.
>> 
>> Baloney.
>> 
>> It's written in an older style, sure, but it's remarkably bug free considering how complex it is. The complexity is a result of the fiendishly complex x86 instructions set.
>> 
>> The proof of its quality is it has successfully been extended from a purely 16 bit generator to 32 and extended again to 64 bit, and has been extended to support multiple ABIs and object file formats.
>> 
>> The DFA optimizer has also proven to be fast and very robust.
>
> Unfortunately, the GDC and LDC optimizers consistently produce code that outperforms code generated by the DMD backend by 20-30%, sometimes as high as 40% for CPU-intensive code. DMD also tends to have more codegen bugs when run with -O -inline (which, ironically, still produces inferior code to what LDC/GDC produces with -O).

I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.

On Sunday, 16 February 2020 at 10:52:33 UTC, NaN wrote:
> On Sunday, 16 February 2020 at 00:16:24 UTC, H. S. Teoh wrote:
>> [Moving this to separate thread because it's tangential to DIP 1031 discussion.]
>>
>> On Sat, Feb 15, 2020 at 03:59:39PM -0800, Walter Bright via Digitalmars-d wrote:
>>> On 2/15/2020 9:58 AM, jxel wrote:
>>> > how poor quality the backend code is.
>>> 
>>> Baloney.
>>> 
>>> It's written in an older style, sure, but it's remarkably bug free considering how complex it is. The complexity is a result of the fiendishly complex x86 instructions set.
>>> 
>>> The proof of its quality is it has successfully been extended from a purely 16 bit generator to 32 and extended again to 64 bit, and has been extended to support multiple ABIs and object file formats.
>>> 
>>> The DFA optimizer has also proven to be fast and very robust.
>>
>> Unfortunately, the GDC and LDC optimizers consistently produce code that outperforms code generated by the DMD backend by 20-30%, sometimes as high as 40% for CPU-intensive code. DMD also tends to have more codegen bugs when run with -O -inline (which, ironically, still produces inferior code to what LDC/GDC produces with -O).
>
> I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.

This discussion has veered off topic. Let's please stick to discussion the DIP. Thanks!

On Sunday, 16 February 2020 at 10:55:26 UTC, Mike Parker wrote:
> This discussion has veered off topic. Let's please stick to discussion the DIP. Thanks!

Hence why it was split off into a different thread...

On Sunday, 16 February 2020 at 11:06:53 UTC, Nicholas Wilson wrote:
> On Sunday, 16 February 2020 at 10:55:26 UTC, Mike Parker wrote:
>> This discussion has veered off topic. Let's please stick to discussion the DIP. Thanks!
>
> Hence why it was split off into a different thread...

Didn't catch that. Thanks.

On 2/16/2020 2:52 AM, NaN wrote:
> I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.

The SIMD code was substantially improved a year or two ago. I added common subexpression support and improved the register allocator for it.

The main problem is I made a mistake in putting the inliner in the DMD front end. It should be in the back end, where it'll be a lot more effective.

On 17/02/2020 11:15 AM, Walter Bright wrote:
> On 2/16/2020 2:52 AM, NaN wrote:
>> I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.
> 
> The SIMD code was substantially improved a year or two ago. I added common subexpression support and improved the register allocator for it.
> 
> The main problem is I made a mistake in putting the inliner in the DMD front end. It should be in the back end, where it'll be a lot more effective.

Perhaps you could mentor somebody in say SaoC to build that up?

A chance to do that for an inspiring compiler dev would be invaluable.

On Sunday, 16 February 2020 at 22:29:01 UTC, rikki cattermole wrote:
> On 17/02/2020 11:15 AM, Walter Bright wrote:
>> On 2/16/2020 2:52 AM, NaN wrote:
>>> I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.
>> 
>> The SIMD code was substantially improved a year or two ago. I added common subexpression support and improved the register allocator for it.
>> 
>> The main problem is I made a mistake in putting the inliner in the DMD front end. It should be in the back end, where it'll be a lot more effective.
>
> Perhaps you could mentor somebody in say SaoC to build that up?
>
> A chance to do that for an inspiring compiler dev would be invaluable.

Or it could be a good project for GSOC if we get accepted, but Walter should be willing to mentor the student.

On Sunday, 16 February 2020 at 22:15:22 UTC, Walter Bright wrote:
> On 2/16/2020 2:52 AM, NaN wrote:
>> I was seeing worse than that last time i used DMD, it was mostly int code, no fpu, and it was around 60% slower with DMD than LDC. Haven't used it since. SIMD support with DMD was awful at the time too, dont know if thats improved.
>
> The SIMD code was substantially improved a year or two ago. I added common subexpression support and improved the register allocator for it.
>
> The main problem is I made a mistake in putting the inliner in the DMD front end. It should be in the back end, where it'll be a lot more effective.

Replying here so as not to pollute the other thread.
Since PR are welcome, can you please take care of https://github.com/dlang/dmd/pull/10200 which hasn't been reviewed for 6+ months ?

This is the main concern I have with the DMD backend: while it's an incredible one-man effort (and I don't think people are giving you enough credit for this achievement), it *is* a one-man effort, with a bus factor of 1.

It does produce slower code than other backends, generate worse debug infos (DWARF debug infos are completely broken on OSX), does not support cross-compilation except for `-m32`/`-m64` and has a few ABI issues which haven't been solved in years. And that's completely understandable, given that amount of work required to make things work.

That being said, DMD is still my default compiler for its compilation speed (although it's loosing a bit more with every release).

On 2/16/2020 6:07 PM, Mathias Lang wrote:
> (DWARF debug infos are completely broken on OSX),
I hear this now and then about the DWARF output, but there are ZERO bug reports on it.

I use gdb myself on OSX and Linux, and while I don't much care for gdb, it works.