On Mon, 31 May 2010 19:09:06 -0400, dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
retard wrote:
> Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
>
>> On 05/31/2010 05:43 PM, retard wrote:
>>> DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
>>
Walter Bright, el 1 de junio a las 17:18 me escribiste:
> Leandro Lucarella wrote:
> >LTO is not only targeted at C++. I don't have numbers to talk seriously
> >about how a big gain is for C though, which might be closer to D in
> >terms of parse time compared with the whole compilation process. E
Walter Bright wrote:
I gotta believe that if you're writing Fortran functions and expecting
them to be inlined into C code, or other such function-by-function
language mixing, things are getting desperate.
I have experienced a runtime disaster after executing exe which
successfully linked
Leandro Lucarella wrote:
LTO is not only targeted at C++. I don't have numbers to talk seriously
about how a big gain is for C though, which might be closer to D in
terms of parse time compared with the whole compilation process. Even
more, you can do LTO for object files generated from different
Don, el 1 de junio a las 20:15 me escribiste:
> Michiel Helvensteijn wrote:
> >Adam Ruppe wrote:
> >
> >>>You save time by recompiling only files that have changes.
> >>But, then the whole program goes through the process again anyway to
> >>perform the optimization. You save a little time in skip
Andrei Alexandrescu wrote:
On 06/01/2010 01:42 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
I now realize that for large projects a future need would be for dmd
to read files off the standard input. The length of the command line
is limited.
dmd can read command lines from a file with
On 06/01/2010 01:42 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
I now realize that for large projects a future need would be for dmd
to read files off the standard input. The length of the command line
is limited.
dmd can read command lines from a file with the:
dmd @command.txt
synt
Adam Ruppe wrote:
You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to
perform the optimization. You save a little time in skipping parts of
the front end for unchanged file, but the whole backend process has to
happen a
Lurker wrote:
Walter Bright wrote:
"Essentially, link time optimization is a hack to get around the language
problem C/C++ have with their separate compilation model."
I know what you meant, but to be correct: C/C++ have INDEPENDENT
compilation, not SEPARATE compilation; Ada has SEPARATE compil
Vladimir Panteleev wrote:
Doesn't this mean that standard library functions will never be inlined?
The standard library functions can be inlined despite them being in phobos.lib
because the compiler still has access to the source code for them.
Andrei Alexandrescu wrote:
I now realize that for large projects a future need would be for dmd to
read files off the standard input. The length of the command line is
limited.
dmd can read command lines from a file with the:
dmd @command.txt
syntax. There is no limit to the command line
Walter Bright wrote:
"Essentially, link time optimization is a hack to get around the language
problem C/C++ have with their separate compilation model."
I know what you meant, but to be correct: C/C++ have INDEPENDENT
compilation, not SEPARATE compilation; Ada has SEPARATE compilation, for
examp
Michiel Helvensteijn wrote:
Adam Ruppe wrote:
You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to
perform the optimization. You save a little time in skipping parts of
the front end for unchanged file, but the whole ba
Adam Ruppe wrote:
>> You save time by recompiling only files that have changes.
>
> But, then the whole program goes through the process again anyway to
> perform the optimization. You save a little time in skipping parts of
> the front end for unchanged file, but the whole backend process has to
On 6/1/10, Michiel Helvensteijn wrote:
> Walter Bright wrote:
>
>> The link-time optimization is essentially compiling the whole project
>> anyway,
>
> That makes no sense.
In simple terms, that is what it is though!
http://gcc.gnu.org/wiki/LinkTimeOptimization
"Link Time Optimization (LTO) give
Walter Bright wrote:
> The link-time optimization is essentially compiling the whole project
> anyway,
That makes no sense.
> so I don't see how you're saving any time with it over D's approach.
You save time by recompiling only files that have changes.
More importantly, what if you only have
Andrei Alexandrescu, el 1 de junio a las 08:23 me escribiste:
> On 06/01/2010 04:57 AM, Walter Bright wrote:
> >Alex Makhotin wrote:
> >>So the best way to build release version(assuming two-phase build)
> >>should be:
> >>
> >>1. Synchronize DMD compilation switches with DMD link
> >>switches(-re
On 01.06.2010 16:23, Andrei Alexandrescu wrote:
I now realize that for large projects a future need would be for dmd to
read files off the standard input. The length of the command line is
limited.
Andrei
"dmd @cmdfile" is often used for that purpose.
On 06/01/2010 04:57 AM, Walter Bright wrote:
Alex Makhotin wrote:
So the best way to build release version(assuming two-phase build)
should be:
1. Synchronize DMD compilation switches with DMD link
switches(-release -O -inline).
2. Pass all the project sources in one DMD cmd line, compile.
3. L
On 2010-06-01 12:01, Vladimir Panteleev wrote:
On Tue, 01 Jun 2010 10:56:47 +0300, Alex Makhotin wrote:
So the best way to build release version(assuming two-phase build)
should be:
1. Synchronize DMD compilation switches with DMD link
switches(-release -O -inline).
2. Pass all the project so
Vladimir Panteleev wrote:
I assume that the standard library is not subjected to link-time
optimization, because all code is used from the .lib.
What I think is that the libphobos2.a and libdruntime.a should be
available with and without debug information so that the user may choose
which
Walter Bright wrote:
Does single-phase(compile-link in one command line) give optimization
gain with the DMD?
Yes.
OK, currently I use two step build system, it looks reasonable to
implement this scheme for release build.
--
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com
On Tue, 01 Jun 2010 10:56:47 +0300, Alex Makhotin wrote:
So the best way to build release version(assuming two-phase build)
should be:
1. Synchronize DMD compilation switches with DMD link switches(-release
-O -inline).
2. Pass all the project sources in one DMD cmd line, compile.
3. Link
Alex Makhotin wrote:
So the best way to build release version(assuming two-phase build)
should be:
1. Synchronize DMD compilation switches with DMD link switches(-release
-O -inline).
2. Pass all the project sources in one DMD cmd line, compile.
3. Link produced object file with other libs.
Walter Bright wrote:
retard wrote:
I thought the DMD's approach required sources for each module and GCC
supported LTO even when only object / library files were provided.
DMD does require the sources, or at least the sources you'd like to have
inlined. GCC requires all the sources used to be
Leandro Lucarella wrote:
Walter Bright, el 31 de mayo a las 15:41 me escribiste:
To say D code is slower because it lacks link-time optimization is a
false supposition.
Yeah, but you can't get link-time optimization if you compile each file
separately (to enable partial compilation when you ch
Walter Bright, el 31 de mayo a las 15:41 me escribiste:
> retard wrote:
> >Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
> >
> >>On 05/31/2010 05:43 PM, retard wrote:
> >>>DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
> >>For very special values of much, I suppose.
> >
> >Polymorp
retard wrote:
I thought the DMD's approach required sources for each module and GCC
supported LTO even when only object / library files were provided.
DMD does require the sources, or at least the sources you'd like to have
inlined. GCC requires all the sources used to be compiled with a speci
Mon, 31 May 2010 15:41:00 -0700, Walter Bright wrote:
> retard wrote:
>> Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
>>
>>> On 05/31/2010 05:43 PM, retard wrote:
DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
>>> For very special values of much, I suppose.
>>
>> Polymorph
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> retard wrote:
> > Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
> >
> >> On 05/31/2010 05:43 PM, retard wrote:
> >>> DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
> >> For very special values of much, I suppose.
retard wrote:
Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
On 05/31/2010 05:43 PM, retard wrote:
DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization,
floating point
31 matches
Mail list logo
