I neglected point out, however, that the article itself is a home run! Thank you, Vladimir!

I would say opposite :)

On Wed, Nov 21, 2018 at 9:55 PM Walter Bright via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On 11/21/2018 5:55 AM, Guillaume Piolat wrote:
> > On Wednesday, 21 November 2018 at 11:18:22 UTC, Nicholas Wilson wrote:
> >> On Wednesday, 21 November 2018 at 08:07:52 UTC, Vladimir Panteleev
> wrote:
> >>>
> https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/
> >>>
> >>
> >> This is #2 on HN at the moment.
> >
> > I would be wary of such titles.
> >
> > Whatever will remain in minds will be something like "D compilation is
> slow"
> > which isn't accurate when compared to the competition.
> >
> > The article is clever, the title is clever, but most people will only
> read the
> > title.
>
> Unfortunately, you're right. The title will leave the impression "D is
> slow at
> compiling". You have to carefully read the article to see otherwise, and
> few
> will do that.
>

On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote:
> Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that.

Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else.

If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose.

On 11/21/2018 8:48 PM, Vladimir Panteleev wrote:
> On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote:
>> Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that.
> 
> Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else.
> 
> If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose.

It has indeed done well. In fact, the article is so good it is probably worth it to have that attention-getting title. It is a risky strategy, though :-)

On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote:
> Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that.

Well comparative to itself sometimes it is. When you initially write D code you get used to the blazing fast speeds, but when eventually the compilation speed slows down as a project grows then this has a real effect on productivity.

Maybe a better title would have been "D compilation sometimes slows down too much", but it wouldn't get as many hits. On the upside, people who read the article - or even just read the comments section, will quickly realize that D's compilation speed is still miles faster than the competition. They might actually try the language. :)

On Thursday, 22 November 2018 at 10:51:45 UTC, Andrej Mitrovic wrote:

<mega snip>

BTW, it's nice to see again the Secret Squirrel on the forum, in these days: welcome back Andrej!

/Paolo

On Thursday, 22 November 2018 at 11:16:26 UTC, Paolo Invernizzi wrote:
> BTW, it's nice to see again the Secret Squirrel on the forum, in these days: welcome back Andrej!
>
> /Paolo

Oh hey there too! I'm sorry if I can't recall you, though. ¯\_(ツ)_/¯

I mostly lurk around here these days. But I still use D heavily, at work.

On Thursday, 22 November 2018 at 13:19:58 UTC, Andrej Mitrovic wrote:
> On Thursday, 22 November 2018 at 11:16:26 UTC, Paolo Invernizzi wrote:
>> BTW, it's nice to see again the Secret Squirrel on the forum, in these days: welcome back Andrej!
>>
>> /Paolo
>
> Oh hey there too! I'm sorry if I can't recall you, though. ¯\_(ツ)_/¯

Oh, no problem... eheh

> I mostly lurk around here these days.

Yep, the same...

> But I still use D heavily, at work.

Well, the same here; not so heavily right now, my CTO is not sure anymore about the "case for D", but well, we have just delivered a D (medical) codebase to one of our customer...

Let's see...

/Paolo

On 2018-11-21 11:56, Walter Bright wrote:

> Wouldn't it be awesome to have the lexing/parsing of the imports all done in parallel? The main difficulty in getting that to work is dealing with the shared string table.

Would it be possible to have one string table per thread and merge them to one single shared string table before continuing with the next phase?

-- 
/Jacob Carlborg

On Wednesday, 21 November 2018 at 10:56:02 UTC, Walter Bright wrote:
> Wouldn't it be awesome to have the lexing/parsing of the imports all done in parallel?

From my testing lexing/parsing takes small amount of build time so running it in parallel might be small gain. We should consider running in parallel more heavy hitting features like CTFE and templates.

Since we are in wish land here is my wishes. Currently D reads the all files that are passed in command line before starting lexing/parsing, but in principle we could start lexing/parsing after first file is read. In fact we could start after first file`s first line is read. Out of all operation before semantic pass, reading from hard disk should be the slowest so it might be possible to decode utf-8, lex and parse at the speed of reading from hard disk. If we run these steps in different thread on the same core with SMT we could better use core`s resources. Reading file with kernel, decoding UTF-8 with vector instructions and lexing/parsing with scalar operations while all communication is done trough L1 and L2 cache.

I thought about using memory mapped files to unblock file reading as a first step but lack of good documentation about mmf and lack of thorough understanding of front end made me postpone this modification. Its a change with little benefit.

> The main difficulty in getting that to work is dealing with the shared string table.

At begging of parsing a thread could get a read-only shared slice of string table. All strings not in table are put in local string table. After parsing tables are merged and shared slice is updated so new thread could start with bigger table. this assumes that table is not sorted