Hello,


I was talking to Walter on how to define a good study of D's compilation speed. We figured that we clearly need a good baseline, otherwise numbers have little meaning.

One idea would be to take a real, non-trivial application, written in both D and another compiled language. We then can measure build times for both applications, and also measure the relative speeds of the generated executables.

Although it sounds daunting to write the same nontrivial program twice, it turns out such an application does exist: dmdscript, a Javascript engine written by Walter in both C++ and D. It has over 40KLOC so it's of a good size to play with.

What we need is a volunteer who dusts off the codebase (e.g. the D source is in D1 and should be adjusted to compile with D2), run careful measurements, and show the results. Is anyone interested?


Thanks,

Andrei

On 24-Jul-12 18:34, Andrei Alexandrescu wrote:
> Hello,
> Although it sounds daunting to write the same nontrivial program twice,
> it turns out such an application does exist: dmdscript, a Javascript
> engine written by Walter in both C++ and D. It has over 40KLOC so it's
> of a good size to play with.
>
> What we need is a volunteer who dusts off the codebase (e.g. the D
> source is in D1 and should be adjusted to compile with D2), run careful
> measurements, and show the results. Is anyone interested?
>

Well, I'd rather pass this to someone else but I have DMDScript repo that could be built with DMD ~ 2.056. I'll upload it to github, been meaning to do this for ages.


-- 
Dmitry Olshansky

On 7/24/12 10:53 AM, Dmitry Olshansky wrote:
> On 24-Jul-12 18:34, Andrei Alexandrescu wrote:
>> Hello,
>> Although it sounds daunting to write the same nontrivial program twice,
>> it turns out such an application does exist: dmdscript, a Javascript
>> engine written by Walter in both C++ and D. It has over 40KLOC so it's
>> of a good size to play with.
>>
>> What we need is a volunteer who dusts off the codebase (e.g. the D
>> source is in D1 and should be adjusted to compile with D2), run careful
>> measurements, and show the results. Is anyone interested?
>>
>
> Well, I'd rather pass this to someone else but I have DMDScript repo
> that could be built with DMD ~ 2.056. I'll upload it to github, been
> meaning to do this for ages.

Excellent, thanks!

Andrei

On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote:
> the D source is in D1 and should be adjusted to compile with D2),

That would provide performance (compilation and run-time) for D1 only (with D2 compiler). Performance of a typical D2 app would likely be different.

>"Roman D. Boiko"  wrote in message news:hpibxcqsmlpmgyngjzwp@forum.dlang.org...
>On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote:
>> the D source is in D1 and should be adjusted to compile with D2),
>
>That would provide performance (compilation and run-time) for D1 only (with D2 compiler). Performance of a typical D2 app would likely be different.

Still, is a good starting point.

On 24-Jul-12 18:54, Andrei Alexandrescu wrote:
> On 7/24/12 10:53 AM, Dmitry Olshansky wrote:
>> On 24-Jul-12 18:34, Andrei Alexandrescu wrote:
>>> Hello,
>>> Although it sounds daunting to write the same nontrivial program twice,
>>> it turns out such an application does exist: dmdscript, a Javascript
>>> engine written by Walter in both C++ and D. It has over 40KLOC so it's
>>> of a good size to play with.
>>>
>>> What we need is a volunteer who dusts off the codebase (e.g. the D
>>> source is in D1 and should be adjusted to compile with D2), run careful
>>> measurements, and show the results. Is anyone interested?
>>>
>>
>> Well, I'd rather pass this to someone else but I have DMDScript repo
>> that could be built with DMD ~ 2.056. I'll upload it to github, been
>> meaning to do this for ages.
>
> Excellent, thanks!
>
> Andrei
>

Done:
https://github.com/blackwhale/DMDScript

An awful lot of stuff got deprecated, e.g. it still uses
 class A: public B{...} syntax.

To those taking this task - ready your shovels ;)

-- 
Dmitry Olshansky

On 24-Jul-12 18:54, Roman D. Boiko wrote:
> On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote:
>> the D source is in D1 and should be adjusted to compile with D2),
>
> That would provide performance (compilation and run-time) for D1 only
> (with D2 compiler). Performance of a typical D2 app would likely be
> different.

In fact it's rather D2-ified. But yeah, no template heavy code in sight. It doesn't even use std.range/std.algorithm IRC.

-- 
Dmitry Olshansky

On 7/24/12 10:54 AM, Roman D. Boiko wrote:
> On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote:
>> the D source is in D1 and should be adjusted to compile with D2),
>
> That would provide performance (compilation and run-time) for D1 only
> (with D2 compiler). Performance of a typical D2 app would likely be
> different.

Ehm. There's any number of arguments that can be made to question the validity of the study:

* the coding style does not use the entire language in either or both implementations

* the application domain favors one language or the other

* the application's use of libraries is too low/too high

* the translation is too literal

* the translation changes the size of the code (which is the case here, as the D version is actually shorter)

Nevertheless, I think there is value in the study. We're looking at a real nontrivial application that wasn't written for a study, but for actual use, and that implements the same design and same functionality in both languages.


Andrei

On Tuesday, 24 July 2012 at 15:06:58 UTC, Andrei Alexandrescu wrote:
> Nevertheless, I think there is value in the study. We're looking at a real nontrivial application that wasn't written for a study, but for actual use, and that implements the same design and same functionality in both languages.

OK. And it could serve as a basis for further variations:

* introduce some feature (e.g., ranges), measure impact
* measure impact of multiple features alone and in combination

Of course, trivial changes would unlikely yield anything useful, but I believe there is a way to produce valuable data in a controlled research.

On 7/24/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> snip

I've got a codebase where it takes DMD 15 seconds to output an error message to stdout. The error message is 3000 lines long. (and people thought C++ errors were bad!). It's all thanks to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=8082

The codebase isn't public yet so I can't help you with comparisons. Non-release full builds take 16 seconds for a template-heavy ~12k codebase (without counting lines of external dependencies). I use a lot of static foreach loops btw.

Personally I think full builds are very fast compared to C++, although the transition from a small codebase which takes less than a second to compile to a bigger codebase which takes over a dozen seconds to compile is an unpleasant experience. I'd love to see DMD speed up its compile-time features like templates, mixins, static foreach, etc.