With the recent merging of the last of the big files machobj.d:

https://github.com/dlang/dmd/pull/8911

I'm happy to say we're over the hump in converting the backend to D!

Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion.

Thanks to everyone who helped out with this!

Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D.

The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions.

On Tue, Nov 06, 2018 at 02:12:02PM -0800, Walter Bright via Digitalmars-d-announce wrote:
> With the recent merging of the last of the big files machobj.d:
> 
> https://github.com/dlang/dmd/pull/8911
> 
> I'm happy to say we're over the hump in converting the backend to D!
> 
> Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion.
> 
> Thanks to everyone who helped out with this!

Awesome news!


> Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D.

What sort of refactoring are we looking at?  Any low-hanging fruit here that we non-compiler-experts can chip away at?


> The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions.

Finally!


T

-- 
Do not reason with the unreasonable; you lose by definition.

On 11/6/2018 3:00 PM, H. S. Teoh wrote:
> What sort of refactoring are we looking at?  Any low-hanging fruit here
> that we non-compiler-experts can chip away at?

Simply going with foreach loops is a nice improvement.

On Tuesday, 6 November 2018 at 22:12:02 UTC, Walter Bright wrote:
> With the recent merging of the last of the big files machobj.d:
>
> https://github.com/dlang/dmd/pull/8911
>
> I'm happy to say we're over the hump in converting the backend to D!

Great! Although I wish it didn't have to be you mostly doing this grunt work.

> Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion.
>
> Thanks to everyone who helped out with this!
>
> Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D.

I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each:

2.081.2 - 11.5s
2.082.1 - 10.5s
2.083.0 - 9.9s
master  - 10.8s

Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down, but maybe it will get better with refactoring and when the entire backend is compiled at once, rather than the DMD separate compilation used now.

> The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions.

I was going to ask why you wouldn't need those headers for your C/C++ compiler, DMC, but it looks like you've translated that to mostly D already:

https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc

On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote:
> I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each:
>
> 2.081.2 - 11.5s
> 2.082.1 - 10.5s
> 2.083.0 - 9.9s
> master  - 10.8s
>
> Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down

Could this be because you used a LLVM compiler for the C code but a Mars compiler for D code? If one either uses DMC for C or LDC for D, perhaps the results will be better.

On 2018-11-06 23:12, Walter Bright wrote:

> The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions.

Still need some of those for GDC and LDC. Until we have a tool that can automatically generate them.

-- 
/Jacob Carlborg

On Wednesday, 7 November 2018 at 11:22:13 UTC, Dukc wrote:
> On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote:
>> I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each:
>>
>> 2.081.2 - 11.5s
>> 2.082.1 - 10.5s
>> 2.083.0 - 9.9s
>> master  - 10.8s
>>
>> Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down
>
> Could this be because you used a LLVM compiler for the C code but a Mars compiler for D code? If one either uses DMC for C or LDC for D, perhaps the results will be better.

I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Maybe I'd get different results by using different compilers, but these are two fairly fast and commonly used compilers so they're worth checking with.

On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:
> I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D.

Because generally, LLVM compilers provide faster code, but compile slower than Digital Mars compilers AFAIK. So if you compile the D code with DMD but C code with LDC, the program will likely compile faster but execute slower as increasing portions are written in D, compared to using the same backend for both languages.

I'm not sure if you benchmarked the time used to build DMD, or the time used by generated DMD to compile some other program. If it was the former, the "real" result is probably worse than your results. But if it was the latter, it is likely better.

On Wednesday, 7 November 2018 at 15:12:13 UTC, Dukc wrote:
> On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:
>> I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D.
>
> Because generally, LLVM compilers provide faster code, but compile slower than Digital Mars compilers AFAIK. So if you compile the D code with DMD but C code with LDC, the program will likely compile faster but execute slower as increasing portions are written in D, compared to using the same backend for both languages.
>
> I'm not sure if you benchmarked the time used to build DMD, or the time used by generated DMD to compile some other program. If it was the former, the "real" result is probably worse than your results. But if it was the latter, it is likely better.

The former, if it wasn't clear. It's also possible something slowed down building the frontend in successive DMD versions, so ideally I'd only time building the backend for each DMD version, but I haven't looked into that.

On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:
>
> I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D

What did you compared is whether clang or DMD compiles code faster not whether D code compiles faster than C++. To check that you should compile both C++ and D with the same backend.