July 25, 2012
On 07/24/2012 04:54 PM, Joseph Rushton Wakeling wrote:

> Language Compiler Compile time (s) Runtime (s)
> D GDC 1.5 25.3
> D DMD 0.4 52.1
> C++ g++ 2.3 21.8
> C++ Clang++ 1.8 27.6

Those C++ builds have very few C++ source files, right? In my experience each source file takes a few seconds each, except the most trivial ones, because the standard library headers are compiled over and over again. :/

Ali

July 25, 2012
On 2012-07-25 00:18, Jonathan M Davis wrote:

> I don't have any hard evidence for it, but I've always gotten the impression
> that it was templates, mixins, and CTFE which really slowed down compilation.
> Certainly, they increase the memory consumption of the compiler by quite a
> bit. My guess would be that if we were looking to improve the compiler's
> performance, that's where we'd need to focus. But we'd have to actually profile
> the compiler on a variety of projects to be sure of that (which is at least
> partially related to what Andrei is suggesting).

We did some profiling on derelict in the process of adding support for D2. This was mostly testing string mixins, the result was: It's a lot faster to use few string mixins containing a lot of code then using many string mixins containing very little code.

-- 
/Jacob Carlborg
July 25, 2012
On Tuesday, 24 July 2012 at 23:55:03 UTC, Joseph Rushton Wakeling wrote:
>  For a rough comparison: […]

Even for a rough comparison of compile times, you need to include compiler switches used. For example, the difference between Clang -O0 vs. Clang -O3 is usually huge.

David
July 25, 2012
On 25/07/12 09:37, David Nadlinger wrote:
> On Tuesday, 24 July 2012 at 23:55:03 UTC, Joseph Rushton Wakeling wrote:
>>  For a rough comparison: […]
>
> Even for a rough comparison of compile times, you need to include compiler
> switches used. For example, the difference between Clang -O0 vs. Clang -O3 is
> usually huge.

C++ compiler and library flags: -ansi -pedantic -Wall -O3 -march=native -mtune=native -I. -DHAVE_INLINE -lm -lgsl -lgslcblas -lgrsl

dmd and gdmd flags: -O -release -inline (which for gdmd corresponds to -O3 -fweb -frelease -finline-functions -I /usr/local/include/d2/).

And yes, as Ali observed, this is a very small codebase (D is 3 files, 374 lines total; C++ is 18 files, 1266 lines -- so the comparison isn't 100% fair; but on the other hand, that's testament to how D can be used for more elegant code....).
July 25, 2012
Walter Bright Wrote:

-snip-
> (Back in the olden days, when men were men and and the sun revolved about the earth, everyone raved about Borland's compilation speed. In tests I ran myself, I found that it was fast, right up until you hit a certain size of source code, maybe about 5000 lines. Then, it fell off a cliff, and compile speed was terrible. But hey, it looked great in those tiny benchmarks.)
-snip-

Back in the olden days... "[Wirth] used the compiler's self-compilation speed as a measure of the compiler's quality."

http://shootout.alioth.debian.org/dont-jump-to-conclusions.php#app
July 25, 2012
Andrei Alexandrescu Wrote:

-snip-
> Nevertheless there's value in the shootout. Yes, if someone is up for it that would be great.

The Python measurement scripts are here -- http://shootout.alioth.debian.org/download/bencher.zip

The whole ball of wax is available for download as a nightly snapshot, but if it was me I'd take the time to select particular programs from public CVS folders -- http://anonscm.debian.org/viewvc/shootout/shootout/bench/


> I also think if we have the setup ready we could convince the site maintainer to integrate D into the suite.

I don't think so ;-)

July 25, 2012
On 7/25/12 4:37 AM, David Nadlinger wrote:
> On Tuesday, 24 July 2012 at 23:55:03 UTC, Joseph Rushton Wakeling wrote:
>> For a rough comparison: […]
>
> Even for a rough comparison of compile times, you need to include
> compiler switches used. For example, the difference between Clang -O0
> vs. Clang -O3 is usually huge.

Yes, and both debug and release build times are important.

Andrei

July 25, 2012
>beautiful ideas Andrei developed on policy class design

Where would one find these ideas?

July 25, 2012
On 07/25/2012 09:46 AM, ixid wrote:
>> beautiful ideas Andrei developed on policy class design
>
> Where would one find these ideas?
>

There are some papers at Andrei's site:

  http://erdani.com/index.php/articles/

Search for "policy" there. Policy based design is the main topic in Andrei's book, "Modern C++ Design":


http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315

That book covers a publicly-available library, Loki, again by Andrei:

  http://loki-lib.sourceforge.net/

Ali
July 25, 2012
On 7/25/2012 8:13 AM, Andrei Alexandrescu wrote:
> Yes, and both debug and release build times are important.

Optimized build time comparisons are less relevant - are you really willing to trade off faster optimization times for less optimization?

I think it's more the time of the edit-compile-debug loop, which would be the unoptimized build times.