• weaselcat (36/36) Jan 30 2015 Based on a post I saw here I thought it would be fun to see how
• Brian Schott (2/5) Jan 30 2015 You're making a pull request for this, right?
• Vladimir Panteleev (4/7) Jan 30 2015 Can you reproduce this is you interleave a dozen or so runs of
• weaselcat (5/12) Jan 30 2015 Hi,
• Martin Nowak (2/4) Jan 31 2015 Look at the linker map file, maybe one build results in a better

"weaselcat" <weaselcat gmail.com> writes:

Based on a post I saw here I thought it would be fun to see how 
much I could speed up compilation just by using per-file makefiles

I decided to use DCD(server only) as the test bench, as it's 
slightly big with all of its dependencies and takes a medium 
amount of time to build. Plus it already uses make, a prime 
candidate.

I hacked in another rule quickly to compile by file(just used 
LDC's -od & -op flags, took about a minute), and got some 
surprising results that I thought might interest someone here. 
BTW, I use a 6 core CPU on my home computer. The usage seemed to 
drop off a cliff at ~450% CPU though so a strong intel CPU would 
may have had LDC go past DMD.

LDC baseline w/ optimization:  15.402 seconds
LDC baseline no optimization:  8.018  seconds
DMD w/ optimizations:          14.174 seconds
DMD no optimizations:          3.179  seconds
LDC -j6 w/ optimization:       7.708  seconds
LDC -j6 no optimization:       5.210  seconds


Weirdly, it also seemed to run faster.

LDC baseline:
./bin/dcd-server -I /usr/include/dlang/dmd
...
[info ] 49562 symbols cached.
[info ] Startup completed in 776.922 milliseconds.


LDC -j6:
./bin/dcd-server -I /usr/include/dlang/dmd
...
[info ] 49562 symbols cached.
[info ] Startup completed in 744.215 milliseconds.


Wasn't a random occurrence, consistently about 30-40ms shorter 
with the parallel version vs baseline, same flags(except for 
output flags.)
P.S., I actually got worse performance on DMD by trying this. I 
think I remember reading walter say something about DMD being 
optimized for throwing every file at it at once. Although, this 
does enable incremental builds.

"Brian Schott" <briancschott gmail.com> writes:

On Saturday, 31 January 2015 at 03:27:32 UTC, weaselcat wrote:
 Wasn't a random occurrence, consistently about 30-40ms shorter 
 with the parallel version vs baseline, same flags(except for 
 output flags.)

You're making a pull request for this, right?

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Saturday, 31 January 2015 at 03:27:32 UTC, weaselcat wrote:
 Wasn't a random occurrence, consistently about 30-40ms shorter 
 with the parallel version vs baseline, same flags(except for 
 output flags.)

Can you reproduce this is you interleave a dozen or so runs of 
the binaries built with and without -j? Perhaps it is an artifact 
of CPU frequency scaling OSLT.

"weaselcat" <weaselcat gmail.com> writes:

On Saturday, 31 January 2015 at 03:33:26 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 31 January 2015 at 03:27:32 UTC, weaselcat wrote:
 Wasn't a random occurrence, consistently about 30-40ms shorter 
 with the parallel version vs baseline, same flags(except for 
 output flags.)

 Can you reproduce this is you interleave a dozen or so runs of 
 the binaries built with and without -j? Perhaps it is an 
 artifact of CPU frequency scaling OSLT.

Hi,
It seems completely unrelated to the -j flag, just related to 
per-file compilation.

"Martin Nowak" <code dawg.eu> writes:

 It seems completely unrelated to the -j flag, just related to 
 per-file compilation.

Look at the linker map file, maybe one build results in a better 
layout, though the effect should be marginal.