On Thursday, 20 July 2017 at 12:10:14 UTC, Adrian Matoga wrote:
> On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote:
>> version 2.067 that still had the C++ frontend took more than 100 seconds.
>
> I can hardly believe it. I remember versions 2.05x building in about 11 seconds.

1 cpu on 2.4 GHz Westmere, gcc 6.2 version 2.067

On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> [...]

Could you please create a post on reddit?

Kind regards
André

On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote:
> version 2.067 that still had the C++ frontend took more than 100 seconds. I think if the backend is translated to D, building the compiler will take not more than 2 seconds.

Using ccache solves the (tiny) problem as the backend hardly every changes.
But even without ccache `make -C src -f posix.mak ../generated/linux/release/64/backend.a -j8` runs in about a second on my machine, hardly anything that needs optimization given that it's a solid codebase with little ongoing development.
Also translating the C++ backend to D zero benefit to D users (at worst it introduces codegen bugs). I'm inclined to say we should rather spent our time on the various more important issues.
It was a good move for the frontend as that will allow us to make use of D features to improve the code/architecture and to eventually turn it into a proper library.
Converting the stable and well tested codebase of the backend, which will hardly receive any feature development, is unlikely to ever pay off.

On Thursday, 20 July 2017 at 18:22:36 UTC, Patrick Schluter wrote:
> 1 cpu on 2.4 GHz Westmere, gcc 6.2 version 2.067

They don't sell single-core CPUs any longer ;). What matters is the time you have to wait.

On 7/20/2017 1:20 AM, Vladimir Panteleev wrote:
> Later that day, I mentioned in passing that we might make building D part of the build process (of a project using D code), since building the compiler took only 3 seconds on my machine.
> 
> To quote my colleague:
> 
> "Whaaaaaaaaaaat? How can a compiler compile in 3 seconds?!"

Back in the 80's (!) computer magazines regularly ran C compiler benchmark results. (At one time I counted 30 C compilers available for the PC.)

I took a class at Standford on compilers, which included a lot of info on data flow analysis. I decided to implement it. Data flow analysis optimizations basically deleted the benchmark code, because it didn't do anything (lots of dead assignments). This compiler was released as Datalight Optimum C.

The article writer concluded that the compiler had a giant bug in it, because it ran the benchmarks impossibly fast, because it deleted the dead code. Instead of being lauded as the only C compiler on the PC that did global data flow analysis, it was labeled as a buggy piece of crap.

By the time we dug ourselves out of that PR disaster, other compilers had implemented it, too.

Ironically, these days DMD gets repeatedly charged with not doing data flow analysis, and clang is assumed to have invented data flow analysis.

Just goes to show the power of marketing :-)

On 7/22/2017 2:04 AM, Martin Nowak wrote:
> Also translating the C++ backend to D zero benefit to D users (at worst it introduces codegen bugs). I'm inclined to say we should rather spent our time on the various more important issues.
> It was a good move for the frontend as that will allow us to make use of D features to improve the code/architecture and to eventually turn it into a proper library.
> Converting the stable and well tested codebase of the backend, which will hardly receive any feature development, is unlikely to ever pay off.

It'll be converted anyway. :-)

I'm about half way through converting the DMC++ front end. It isn't as difficult as I expected. The -betterC is helping a lot, as well as the fact that DMC++ is still pretty much C code. Some years back Daniel Murphy and I removed a lot of the preprocessor trickery from it, which helps, too.

Note that DMC++ is now Boost licensed as well.

Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it!

On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Glad to announce D 2.075.0.
>

I've published a post on the blog to announce the release there. For future releases, I'll be coordinating with Martin so that I can time the blog posts to go out on the same day as the forum announcements. This will give us something more redditable than the forum announcement or the changelog.

Blog:
https://dlang.org/blog/2017/07/24/new-d-compiler-release-dmd-2-075-0/

Reddit:
https://www.reddit.com/r/programming/comments/6p89zj/new_d_compiler_release_dmd_20750/

On Monday, 24 July 2017 at 13:18:01 UTC, Mike Parker wrote:
> On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Glad to announce D 2.075.0.
>>
>
> I've published a post on the blog to announce the release there. For future releases, I'll be coordinating with Martin so that I can time the blog posts to go out on the same day as the forum announcements. This will give us something more redditable than the forum announcement or the changelog.
>
> Blog:
> https://dlang.org/blog/2017/07/24/new-d-compiler-release-dmd-2-075-0/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/6p89zj/new_d_compiler_release_dmd_20750/

typo: "module structure is avaialble"

On Monday, 24 July 2017 at 17:18:53 UTC, Joakim wrote:

> typo: "module structure is avaialble"

Fixed. Thanks.

On Saturday, 22 July 2017 at 21:22:00 UTC, Walter Bright wrote:
> Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it!

One thing to watch out for, though, is that if the D frontend starts using features introduced after its conversion to D, we are going to need to explicitly document the bootstrapping path (right now it's still simple enough with `C++ compiler -> D compiler with 2.068.2 frontend (e.g. ldc 0.17.x) -> Latest D compiler`).