On Saturday, 19 December 2020 at 19:34:32 UTC, Max Haughton wrote:
> You realise that that 80% (450k overall, backend is 90k) of the code in has nothing to do with the code generation.

You realise that creating a high quality backend that is 100% bug free takes a lot of effort and that you have to maintain it in perpetuity? It isn't sufficient that someone "just does it", it also has to be correct, efficient and updated.

> Apple are also pretty reticent to upstream stuff to LLVM but that doesn't really matter because the dmd backend isn't and shouldn't be complicated enough to need that information.

It isn't even obvious that Apple will release the full ISA for their future ARM CPUs.

On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 19 December 2020 at 19:34:32 UTC, Max Haughton wrote:
>> You realise that that 80% (450k overall, backend is 90k) of the code in has nothing to do with the code generation.
>
> You realise that creating a high quality backend that is 100% bug free takes a lot of effort and that you have to maintain it in perpetuity? It isn't sufficient that someone "just does it", it also has to be correct, efficient and updated.
>
>> Apple are also pretty reticent to upstream stuff to LLVM but that doesn't really matter because the dmd backend isn't and shouldn't be complicated enough to need that information.
>
> It isn't even obvious that Apple will release the full ISA for their future ARM CPUs.

DMD is good enough, this discussion is pointless.

The ISA isn't the problem, Apple will probably stick with arm but knowing the parameters to tweak the instruction scheduling is the kind of thing they're being coy with that matter.

On Saturday, 19 December 2020 at 19:44:29 UTC, Max Haughton wrote:
> DMD is good enough, this discussion is pointless.

I think the point was lost, then. Implementing it is less than 10% of the total work. You also need to write exhaustive tests, maintain it and update it. So whoever implements ARM support has to stick around. It is worse to add support for something that falls into decay than not having it in the first place.

On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim Grøstad wrote:
>
> You realise that creating a high quality backend that is 100% bug free takes a lot of effort and that you have to maintain it in perpetuity? It isn't sufficient that someone "just does it", it also has to be correct, efficient and updated.
>

This post made me think.

https://forum.dlang.org/post/umfqzznlrongfrvictus@forum.dlang.org

Read point number 3.


Basically, there are problems with DMD, sometimes crashes and has codegen bugs. Codegen bugs is definitely not something you want in a big project because they are time consuming.

Thank you for posting real commercial experience with D. If I was a hard headed boss of the D project I would probably demand that the DMD backend would be scrapped and efforts should focus on stability with the support of GCC and LLVM backends.

On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:
> Basically, there are problems with DMD, sometimes crashes and has codegen bugs. Codegen bugs is definitely not something you want in a big project because they are time consuming.

Yes, but it is ok for developing a reference compiler, but there is no need for ARM support to do that either. One can run x86 code on ARM CPUs using an emulator for testing. It is a matter of setting up a more generic testing environment.

In fact, as was mentioned earlier one could do idealized code gen for a virtual machine if front end deveopment was the main issue. Might be a good idea actually, regarding CTFE.

On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
> On 19.12.20 18:15, claptrap wrote:
>> 
>> 2. People could just add it to LLVM if they want i think. Might even be easier to write a whole new backend from scratch, i dont know. IE. Not having DMD doesnt preclude the benefit that Walter claims DMD gives us.
>> 
>
> Building LLVM from scratch takes multiple hours. Building DMD from scratch (including backend) takes _seconds_.

Anyone that says LLVM takes multiple hours obviously hasn't built it, or are using a 20 year old computer to build it.

Once you build LLVM you don't build it again. Unless you are modifying LLVM itself, which LDC only has one or two commits that make changes, for Android for local thread storage. So if you are developing a compiler it would still only take seconds.

> Why is it so hard to believe that this is a benefit that an actual compiler developer might care for? It's exactly the prevalence of this kind of common sense pragmatics that makes D so convenient to use despite all flaws. You lose that if you start adding dependencies on projects that lack it.

The user base that compiles DMD is infinitely smaller than the amount that use it. The only opinion I've heard from the D dev team is that they hate the backend and see the DMD backend as obsolete. So not sure who you are really referring to here, in reality.

> Anyway, I think the solution is not to change the default development compiler, it's to get rid of that concept by improving separation of frontend and backends in the frontend development workflow so that it becomes equally convenient to develop frontend patches against every backend. (Though it may be possible to make the case that this would happen more quickly if LLVM or GCC were made the default backend, as it's plausible that the developers of LDC and GDC are more aware of what needs to be done in that department.)

One of the benefits of having your own backend is that you have control over it right? I don't think anyone here would disagree the current backend is garbage. It is legacy C, it is difficult to read and write and is full of bugs. All the while only one person is really working on it.

Since we have full control why isn't a better backend created? This is indicative of the real problems that are being faced. Lack of manpower.

On Saturday, 19 December 2020 at 20:36:07 UTC, Jeeferson wrote:
> On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
>> On 19.12.20 18:15, claptrap wrote:
>>> 
>>> 2. People could just add it to LLVM if they want i think. Might even be easier to write a whole new backend from scratch, i dont know. IE. Not having DMD doesnt preclude the benefit that Walter claims DMD gives us.
>>> 
>>
>> Building LLVM from scratch takes multiple hours. Building DMD from scratch (including backend) takes _seconds_.
>
> Anyone that says LLVM takes multiple hours obviously hasn't built it, or are using a 20 year old computer to build it.
>
> Once you build LLVM you don't build it again. Unless you are modifying LLVM itself, which LDC only has one or two commits that make changes, for Android for local thread storage. So if you are developing a compiler it would still only take seconds.

To add onto that, you can also down it prebuilt, it also available on most Linux distros because it is so widely used and adopted. So you won't be building it yourself most of the time anyways.

On Saturday, 19 December 2020 at 19:24:34 UTC, Adam D. Ruppe wrote:
> On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
>> Why is it so hard to believe that this is a benefit that an actual compiler developer might care for?
>
> Yes, this is important.
>
> I have done patches to dmd myself. It is very quick and accessible.
>
> [...]
>
> still isn't too hard. Way faster and much less scary = more likely to get new dev work done.

+1

Wouldn't (couldn't) have contributed to DMD if it wasn't as simple as it is.
It's super cool when your modified compiler is just a few seconds of compilation way.


In comparison to that, testing some changes to the DUB registry requires me to setup some MongoDB server in advance. And configure it accordingly. And maybe patch some code to not bug me with it's auth process or whatsoever…
Without some (time consuming) help by WebFreak dub-registry PR #474 wouldn't have been a thing.

For DMD you just run the build script. No need to prepare some LLVM or whatever dependency (maybe even in some specific expected versions) in advance.

- Elias

On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:
>
> Basically, there are problems with DMD, sometimes crashes and has codegen bugs. Codegen bugs is definitely not something you want in a big project because they are time consuming.
>
> Thank you for posting real commercial experience with D. If I was a hard headed boss of the D project I would probably demand that the DMD backend would be scrapped and efforts should focus on stability with the support of GCC and LLVM backends.

+1

LDC build process is fast with LLVM installed, and you need LLVM or GCC anyway if you are work on non-toy projects.


I do my developer process with LDC -O0 -g -fsanitize=address -fsanitize=thread, use Makefile without DUB/druntime/phobos.  LLVM sanitizer made my work down quick and solid, and have multi platform cross build is just awesome.

I use to like DMD fast build experience, the price is get some hard to resolve mysterious bugs.  Then I refactor my work without use DUB/druntime/Phobos, I still get keep the lightning build speed and have multi platform ability with great code generate quality.

In my opinion, Walter is artist and have power to performance the magic.  Average Joe play DMD just like boy play toys.   There is nothing wrong with that, just not suit for average Joe like me made living from the jungle.

On 19.12.20 21:36, Jeeferson wrote:
> On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
>> On 19.12.20 18:15, claptrap wrote:
>>>
>>> 2. People could just add it to LLVM if they want i think. Might even be easier to write a whole new backend from scratch, i dont know. IE. Not having DMD doesnt preclude the benefit that Walter claims DMD gives us.
>>>
>>
>> Building LLVM from scratch takes multiple hours. Building DMD from scratch (including backend) takes _seconds_.
> 
> Anyone that says LLVM takes multiple hours obviously hasn't built it, or are using a 20 year old computer to build it.
> ...

False. Maybe it improved in the meantime, maybe there were some missing flags to the cmake invocation. (Also, you are assuming the build just works if you follow the instructions.)

> Once you build LLVM you don't build it again.

My point was there's some value in simplifying initial setup. Git clone and get started. Dependencies on a huge C++ project can be more painful than not having those dependencies.

> ...
> 
> The user base that compiles DMD is infinitely smaller than the amount that use it.

False, there's a positive number of people working on DMD (and they are the ones who actually decide what happens to the backend).

> The only opinion I've heard from the D dev team is that they hate the backend and see the DMD backend as obsolete.

So either you don't read or Walter is not on the dev team. Got it.

> So not sure who you are really referring to here, in reality.
> 

I have contributed language features to the frontend and not having to deal with getting LLVM setup right was a plus. (I never said I couldn't be bothered to do it.)

>> Anyway, I think the solution is not to change the default development compiler, it's to get rid of that concept by improving separation of frontend and backends in the frontend development workflow so that it becomes equally convenient to develop frontend patches against every backend. (Though it may be possible to make the case that this would happen more quickly if LLVM or GCC were made the default backend, as it's plausible that the developers of LDC and GDC are more aware of what needs to be done in that department.)
> 
> One of the benefits of having your own backend is that you have control over it right? I don't think anyone here would disagree the current backend is garbage. It is legacy C, it is difficult to read and write and is full of bugs. All the while only one person is really working on it.
> 
> Since we have full control why isn't a better backend created? This is indicative of the real problems that are being faced. Lack of manpower.
> 

I really hate the way some people just assume there are two positions on any given matter and start superficially classifying people into one of two stances. My point was that it's stupid to claim the DMD backend does not have _any_ benefits over LLVM. Anyone should be able to agree with that, it's completely obvious no matter how you stand on whether or not work on the DMD backend should continue or not.