July 27, 2012
On 26 July 2012 23:07, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 26/07/12 20:27, David Nadlinger wrote:
>>
>> GDC probably performs inlining by default on -O2/-O3, just like LDC does.
>
>
> I was surprised that using -inline alone (without any optimization option) doesn't produce any meaningful improvement.  It cuts maybe 1s off the DMD-compiled runtime, but it's not clear to me that actually corresponds to a reliable difference.  Perhaps GDC just ignores the -inline flag ... ?
>

-inline is mapped to -finline-functions in GDC.  Inlining is possibly done, but only in the backend.

Some extra notes to bear in mind about GDC.
1) All methods and function literals are marked as 'inline' by default.
2) Cross module inlining does not occur if you are compiling one-at-a-time.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 27, 2012
On 27/07/12 07:29, Iain Buclaw wrote:
> -inline is mapped to -finline-functions in GDC.  Inlining is possibly
> done, but only in the backend.
>
> Some extra notes to bear in mind about GDC.
> 1) All methods and function literals are marked as 'inline' by default.
> 2) Cross module inlining does not occur if you are compiling one-at-a-time.

Good to know.  In this case it's all compiled together in one go:

###############################################
DC = gdmd
DFLAGS = -O -release -inline
DREGSRC = dregs/core.d dregs/codetermine.d

all: test

test: test.d $(DREGSRC)
      $(DC) $(DFLAGS) -of$@ $^

.PHONY: clean

clean:
      rm -f test *.o
###############################################

I'm just surprised that using -inline produces no measurable difference at all in performance for GDC, whether or not any other optimization flags are used. As I said, maybe I'll test some manual inlining and see what difference it might make ...
July 27, 2012
On 27 July 2012 09:09, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 27/07/12 07:29, Iain Buclaw wrote:
>>
>> -inline is mapped to -finline-functions in GDC.  Inlining is possibly done, but only in the backend.
>>
>> Some extra notes to bear in mind about GDC.
>> 1) All methods and function literals are marked as 'inline' by default.
>> 2) Cross module inlining does not occur if you are compiling
>> one-at-a-time.
>
>
> Good to know.  In this case it's all compiled together in one go:
>
> ###############################################
> DC = gdmd
> DFLAGS = -O -release -inline
> DREGSRC = dregs/core.d dregs/codetermine.d
>
> all: test
>
> test: test.d $(DREGSRC)
>       $(DC) $(DFLAGS) -of$@ $^
>
> .PHONY: clean
>
> clean:
>       rm -f test *.o
> ###############################################
>
> I'm just surprised that using -inline produces no measurable difference at all in performance for GDC, whether or not any other optimization flags are used. As I said, maybe I'll test some manual inlining and see what difference it might make ...

My best assumption would be it may say something more about the way the program was written itself rather than the compiler.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 28, 2012
On Thursday, 26 July 2012 at 18:57:30 UTC, Jacob Carlborg wrote:
> On 2012-07-26 19:54, Ali Çehreli wrote:
>
>> GNU make has the special $? prerequisite that may help with the above:
>> "The names of all the prerequisites that are newer than the target, with
>> spaces between them. "
>>
>>
>> http://www.gnu.org/software/make/manual/make.html#index-g_t_0024_003f-944
>>
>> Ali
>>
>
> I'm trying to avoid "make" as much as possible.

+1
August 24, 2012
On Tue, 24 Jul 2012 10:34:57 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> 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.

Might I draw attention again to this bug:

http://d.puremagic.com/issues/show_bug.cgi?id=4900

Granted, this is really freaking old.  A re-application of profiling should be done.

But in general, what I have observed from DMD compiling is that the number and size (string size) of symbols is what really bogs it down.  Most of the time, it's lightning fast.

The reason the dcollections unit test taxes it so much is because I'm instantiating 15 objects for each container type, and each one has humongous symbols, a consequence of so many template arguments.

-Steve
August 24, 2012
On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote:
> 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

You can try testing DMD (written in C++) against DDMD (written in D). I don't think you can find more fair comparison (both projects are in sync - though dated - and project size is fairly large).
1 2 3 4 5 6 7
Next ›   Last »