www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D slower than C++ in compile time

reply Frank Benoit <keinfarbton googlemail.com> writes:
Gregor once explained why build tools need to call DMD once per file:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=57473

This makes dsss look like it is slow, but actually this is a concequence 
of a DMD workaround.

For the DWT library this would lead to compile times >15 minutes!

In the past I found the compile times always a big argument for D. 
Hopefully this point gets attention at digitalmars ;)
Feb 16 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Frank Benoit escribi:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 
 
 
 This makes dsss look like it is slow, but actually this is a concequence 
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


Descent will probably do incremental compiling in the next release. Does 
what Gregor say also affects it? If so, vote++ :)
Feb 16 2008
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Ary Borenszweig wrote:

 Frank Benoit escribió:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 


 This makes dsss look like it is slow, but actually this is a 
 concequence of a DMD workaround.

 For the DWT library this would lead to compile times >15 minutes!

 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


 
 Descent will probably do incremental compiling in the next release. Does 
 what Gregor say also affects it? If so, vote++ :)


IIRC, Gregor made this change because all-at-once compilation causes 
some code generation errors/bugs because some code generated code is not 
marked correctly. I don't remember the details, though, or what it 
exactly affects..
Feb 16 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Alexander Panek schrieb:

 Ary Borenszweig wrote:

 Frank Benoit escribi:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 


 This makes dsss look like it is slow, but actually this is a 
 concequence of a DMD workaround.

 For the DWT library this would lead to compile times >15 minutes!

 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


 Descent will probably do incremental compiling in the next release. 
 Does what Gregor say also affects it? If so, vote++ :)




yes.


 
 IIRC, Gregor made this change because all-at-once compilation causes 
 some code generation errors/bugs because some code generated code is not 
 marked correctly. I don't remember the details, though, or what it 
 exactly affects..


is the link not working?
Feb 16 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
It will if I want to do any incremental compiling, which is what I've started
in Trunk. It's not too late to change this, so I think I'll make an option
"allow incremental compilation" or something. If that's off, it'll just pass
the compiler a huge list of files. A era fix would be awesome though. 

Ary Borenszweig Wrote:


 Frank Benoit escribi:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 
 
 
 This makes dsss look like it is slow, but actually this is a concequence 
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


 
 Descent will probably do incremental compiling in the next release. Does 
 what Gregor say also affects it? If so, vote++ :)
Feb 16 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Frank Benoit wrote:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 
 
 
 This makes dsss look like it is slow, but actually this is a concequence 
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


Ditch DMD for serious work. And the frontend has enough bugs....

It would be nice Walter could add a couple people who just manage 
bugfixes, then put the dmd frontend on dsource.
Feb 16 2008
parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Christopher Wright wrote:

 Ditch DMD for serious work. And the frontend has enough bugs....
 
 It would be nice Walter could add a couple people who just manage 
 bugfixes, then put the dmd frontend on dsource.


Ideally Walter would release his pile of test cases. He's said that one problem 
with patches on Bugzilla is that you can't be sure whether they don't break 
something else. Well, the problem is that whoever writes the patches can't be 
sure either, since he doesn't have all the tests Walter uses.

If we had the tests, we could write patches for the frontend and be able to 
unequivocally state that they work. Plus, it'd help in understanding the 
frontend code - "if I change this all of these stop working, why is that?" - 
which in turn may lead to more patches.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 16 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Matti Niemenmaa escribió:

 Christopher Wright wrote:

 Ditch DMD for serious work. And the frontend has enough bugs....

 It would be nice Walter could add a couple people who just manage 
 bugfixes, then put the dmd frontend on dsource.


 
 Ideally Walter would release his pile of test cases.


Isn't that dstress? There's quite a lot of test code there...
Feb 16 2008
parent Matti Niemenmaa <see_signature for.real.address> writes:
Ary Borenszweig wrote:

 Matti Niemenmaa escribió:

 Ideally Walter would release his pile of test cases.


 
 Isn't that dstress? There's quite a lot of test code there...


I don't think they're the same.

Still, testing against DStress helps, of course.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 17 2008
prev sibling next sibling parent reply Burton Radons <burton-radons shaw.ca> writes:
Frank Benoit Wrote:


 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=57473
 
 This makes dsss look like it is slow, but actually this is a concequence 
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


I don't understand from that link what the problem is. Is there any situation
where if you pass a complete list of D files to DMD that it won't generate the
correct code? Or is this isolated to situations where you're trying to
incrementally compile, which has never worked all that great with DMD and will
very quickly be slower than calling it with everything? All Gregor says is that
it produces larger executables than strictly necessary which is a problem,
sure, but a completely usable workaround and far from the show-stopping bugs
that should be Walter's primary concern right now.

There may be a way to build a more intelligent linker that can produce tighter
executables based on knowledge about how D works. I'll look into it, but I
can't guarantee when.
Feb 16 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Burton Radons wrote:


 Frank Benoit Wrote:
 

 Gregor once explained why build tools need to call DMD once per file:




http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=57473

 
 This makes dsss look like it is slow, but actually this is a concequence
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D.
 Hopefully this point gets attention at digitalmars ;)


 
 I don't understand from that link what the problem is. Is there any
 situation where if you pass a complete list of D files to DMD that it
 won't generate the correct code? Or is this isolated to situations where
 you're trying to incrementally compile, which has never worked all that
 great with DMD and will very quickly be slower than calling it with
 everything? All Gregor says is that it produces larger executables than
 strictly necessary which is a problem, sure, but a completely usable
 workaround and far from the show-stopping bugs that should be Walter's
 primary concern right now.
 
 There may be a way to build a more intelligent linker that can produce
 tighter executables based on knowledge about how D works. I'll look into
 it, but I can't guarantee when.


The link problems have usually stemmed from trying to build libraries which
are then built into an application. Typically the compiler has been so
focused on creating objects for an executable, that there has been missing
and/or conflicting symbols if building an library instead. This has in
particular been a problem with templates, template instances and so.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Feb 16 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.coim> writes:
Christopher Wright Wrote:

 It would be nice Walter could add a couple people who just manage 
 bugfixes, then put the dmd frontend on dsource.


I think what we really need is an entirely separate front-end (GDC and LLVMDC
use DMD's) that would do everything DMD's existing front-end does (lexical,
parsing & semantic analysis, optimization, CTFE interpreting, template
expansion, Ddoc generation, etc.). Hopefully, it would be clearer (DMD's code
is fairly complex...) and ideally it would be written in D, with a simple C or
C++ interface for linking to backends. IMO, it should use the visitor pattern,
so it could be passed a C++ class that would do the code generation, using D2's
C++ interface. This would be easy(ish) to integrate with backends that use
DMD's existing frontend so LLVMDC, GDC and DMD could all use it. It could also
then be integrated into IDEs, static analysis/refactoring tools, code
formatters, whatever, that could make visitors that do things post-semantic
pass.

But all the time I have to spend on D coding, I'd rather spend on Descent.

(Sorry for the web interface; I' not at home right now).
Feb 17 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Robert Fraser wrote:


 Christopher Wright Wrote:

 It would be nice Walter could add a couple people who just manage
 bugfixes, then put the dmd frontend on dsource.


 
 I think what we really need is an entirely separate front-end (GDC and
 LLVMDC use DMD's) that would do everything DMD's existing front-end does
 (lexical, parsing & semantic analysis, optimization, CTFE interpreting,
 template expansion, Ddoc generation, etc.). Hopefully, it would be clearer
 (DMD's code is fairly complex...) and ideally it would be written in D,
 with a simple C or C++ interface for linking to backends. IMO, it should
 use the visitor pattern, so it could be passed a C++ class that would do
 the code generation, using D2's C++ interface. This would be easy(ish) to
 integrate with backends that use DMD's existing frontend so LLVMDC, GDC
 and DMD could all use it. It could also then be integrated into IDEs,
 static analysis/refactoring tools, code formatters, whatever, that could
 make visitors that do things post-semantic pass.
 
 But all the time I have to spend on D coding, I'd rather spend on Descent.
 
 (Sorry for the web interface; I' not at home right now).


Dil?

http://code.google.com/p/dil/

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Feb 17 2008
next sibling parent Robert Fraser <fraserofthenight gmail.coim> writes:
Lars Ivar Igesund Wrote:


 Dil?
 
 http://code.google.com/p/dil/


I did not know about that; yes, that looks like the perfect sort of thing.
Feb 17 2008
prev sibling parent reply Ty Tower <tytower hotmail.com.au> writes:
Lars Ivar Igesund Wrote:
Dil     DIL   Hmm in English Dill is a stupid person as well as a herb

DLL is windows Dynamically Linked Library

It all seems a little close don't you think ?
Feb 18 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Ty Tower wrote:

 Lars Ivar Igesund Wrote:
 Dil     DIL   Hmm in English Dill is a stupid person as well as a herb

 DLL is windows Dynamically Linked Library

 It all seems a little close don't you think ?
   


dil is not dill (notice the extra "L" you've added at the end?)
dil is a Turkish work for "language" so it represents the intention of
the project (a D language compiler).
Do you always assume that everything you read online is in English?
that wouldn't be a smart assumption as most of the world has a different
native language than English.
would you also assume [for example] that "Ubuntu" is some kind of
English word/slang?

-- Yigal
Feb 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:fpbjmj$199t$1 digitalmars.com...

 Ty Tower wrote:

 Lars Ivar Igesund Wrote:
 Dil     DIL   Hmm in English Dill is a stupid person as well as a herb

 DLL is windows Dynamically Linked Library

 It all seems a little close don't you think ?


 dil is not dill (notice the extra "L" you've added at the end?)
 dil is a Turkish work for "language" so it represents the intention of
 the project (a D language compiler).
 Do you always assume that everything you read online is in English?
 that wouldn't be a smart assumption as most of the world has a different
 native language than English.
 would you also assume [for example] that "Ubuntu" is some kind of
 English word/slang?


I think what he's getting at is that while it might be a fine name in 
_Turkish_, in _English_ it sounds a bit funny.  Kind of like how the "Wii" 
gets made fun of because it's a word kids use to talk about going to the 
bathroom.

I've never heard of a "dill" being a stupid person, though.  Maybe that's a 
British thing.  I kind of like dill, it sounds fresh and herby ;)
Feb 18 2008
parent reply Aarti_pl <aarti interia.pl> writes:
Jarrett Billingsley pisze:

 I've never heard of a "dill" being a stupid person, though.  Maybe that's a 
 British thing.  I kind of like dill, it sounds fresh and herby ;) 


He probably meant 'dull'.

BR
Marcin Kuszczak
(aarti_pl)
Feb 18 2008
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 Feb 2008 14:39:49 +0100, Aarti_pl wrote:


 Jarrett Billingsley pisze:

 I've never heard of a "dill" being a stupid person, though.  Maybe that's a 
 British thing.  I kind of like dill, it sounds fresh and herby ;) 


 
 He probably meant 'dull'.
 
 BR
 Marcin Kuszczak
 (aarti_pl)


No, "dill" is an English (and thus Australian) term for a person that is a
little bit silly or thoughtless. It is not very degatory or offensive, even
a bit playful maybe.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 18 2008
parent janderson <askme me.com> writes:
Derek Parnell wrote:

 On Mon, 18 Feb 2008 14:39:49 +0100, Aarti_pl wrote:
 

 Jarrett Billingsley pisze:

 I've never heard of a "dill" being a stupid person, though.  Maybe that's a 
 British thing.  I kind of like dill, it sounds fresh and herby ;) 


 He probably meant 'dull'.

 BR
 Marcin Kuszczak
 (aarti_pl)


 
 No, "dill" is an English (and thus Australian) term for a person that is a
 little bit silly or thoughtless. It is not very degatory or offensive, even
 a bit playful maybe.
 


Right.  A dill is a form of pickle so in essence you're calling someone 
stupid like a pickle.

-Joel
Mar 16 2008
prev sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Mon, 18 Feb 2008 09:38:29 -0000, Yigal Chripun <yigal100 gmail.com>  
wrote:


 Ty Tower wrote:

 Lars Ivar Igesund Wrote:
 Dil     DIL   Hmm in English Dill is a stupid person as well as a herb

 DLL is windows Dynamically Linked Library

 It all seems a little close don't you think ?


 dil is not dill (notice the extra "L" you've added at the end?)
 dil is a Turkish work for "language" so it represents the intention of
 the project (a D language compiler).
 Do you always assume that everything you read online is in English?
 that wouldn't be a smart assumption as most of the world has a different
 native language than English.
 would you also assume [for example] that "Ubuntu" is some kind of
 English word/slang?

 -- Yigal


Anyone else spot the irony in making that complaint in English?
Feb 19 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:

 On Mon, 18 Feb 2008 09:38:29 -0000, Yigal Chripun <yigal100 gmail.com> 
 wrote:
 

 Ty Tower wrote:

 Lars Ivar Igesund Wrote:
 Dil     DIL   Hmm in English Dill is a stupid person as well as a herb






I didn't know that a Dill is a stupid person ... but maybe that says 
something about me. ;-)


 DLL is windows Dynamically Linked Library

 It all seems a little close don't you think ?






Seems fine to me.  Actually my first thought was that "dil" could be 
thought of as an acronym for "D Interface Library" or "D 
Internationalized Library" or "D Implementation Language", "D 
Interpreter Library" or somesuch.  Very good acronym potential there. 
And I'm quite fond of dill, to boot.  What's not to like?

--bb
Feb 19 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Bruce Adams wrote:

 On Mon, 18 Feb 2008 09:38:29 -0000, Yigal Chripun <yigal100 gmail.com>
 wrote:


 Ty Tower wrote:

 Lars Ivar Igesund Wrote:
 Dil     DIL   Hmm in English Dill is a stupid person as well as a herb

 DLL is windows Dynamically Linked Library

 It all seems a little close don't you think ?


 dil is not dill (notice the extra "L" you've added at the end?)
 dil is a Turkish work for "language" so it represents the intention of
 the project (a D language compiler).
 Do you always assume that everything you read online is in English?
 that wouldn't be a smart assumption as most of the world has a different
 native language than English.
 would you also assume [for example] that "Ubuntu" is some kind of
 English word/slang?

 -- Yigal


 Anyone else spot the irony in making that complaint in English?


what's the irony exactly? please enlighten me...
אולי אתה מעדיף שאני אכתוב בעברית?
Feb 20 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Frank Benoit wrote:

 For the DWT library this would lead to compile times >15 minutes!
 


I just tried building dwt-win with and without oneatatime enabled. 
Compiler options are '-O -release -inline'.  My PC is a 1.3 GHz athlon, 
with 896 MB RAM and a fairly fast HD.  I could have left out -inline, 
but the time savings likely wouldn't be significant.

Results:
all at once:    2 mins 27 secs, 5.9MB .lib file
one at a time:  39 minutes, 17 MB .lib file

I only did this once, but I expect the results would be about the same 
each time.  This is pretty ugly.

dwt-win is 6.9 MB of code in 353 files, about the same size as Tango.
Feb 18 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
torhu schrieb:

 dwt-win is 6.9 MB of code in 353 files, about the same size as Tango.


In addition ...
This does not mean it should be equal compile time. dwt uses tango, so 
its about double size of types/declarations for the compiler. So i 
wonder how it grows if you build an application on top of dwt with 
another 300 files :)

I gave it a try to measure both times for linux to compile dwt
dmd options: -g -gc -debug -v
dsss options: -full -v
2.8Ghz 2GB Ram

oneatatime=off :  0:31
oneatatime=on  : 31:49

I would reason, with oneatatime=off we see here a much stronger effect 
of more RAM size and CPU speed. With oneatatime=on the file I/O has much 
more weigth, so here the difference is not so big.
Feb 19 2008
prev sibling next sibling parent Ty Tower <tytower hotmail.com.au> writes:
Yigal Chripun Wrote:

Do you always assume that everything you read online is in English?
 that wouldn't be a smart assumption as most of the world has a different
 native language than English.
 would you also assume [for example] that "Ubuntu" is some kind of
 English word/slang?

 -- Yigal




Ummmm Yep . In fact all of the stuff I read is in English as thats what I
speak. . 
and Ummmm nope  as I speak a little kitchen kaffir too,from my African
experience

Merely pointing out there are connotations in such closeness.
Feb 23 2008
prev sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Frank Benoit schrieb:

 Gregor once explained why build tools need to call DMD once per file:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=57473 
 
 
 This makes dsss look like it is slow, but actually this is a concequence 
 of a DMD workaround.
 
 For the DWT library this would lead to compile times >15 minutes!
 
 In the past I found the compile times always a big argument for D. 
 Hopefully this point gets attention at digitalmars ;)


This bugzilla bug can happen if oneatatime is 'off'.
http://d.puremagic.com/issues/show_bug.cgi?id=1629

Using dsss with oneatatime=off and -full sometimes works around it.
Feb 24 2008