www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd makes D appear slow

reply "weaselcat" <weaselcat gmail.com> writes:
In nearly every benchmark I see D in, the default compiler used 
is dmd which runs computationally intense tasks 4-5x+ slower than 
GDC/LDC

example of a random blog post I found:
http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html

D is up to 10x(!) slower than Rust.

Well... dmd is. Under LDC:
MD5 is 5x faster,
SHA1 is about the same,
SHA256 is 10x faster,
SHA512 is 10x faster.

The kicker?
_all_ of these were faster than the Rust timings(albeit by 5-10%) 
when using LDC.

This isn't the first time I've seen this, in basically every 
benchmark featuring D I have to submit a patch/make a comment 
that dmd shouldn't be used. Make no mistake, this is damaging to 
D's reputation - how well does D's "native efficiency" go over 


LDC and GDC need promoted more.

Bye,
May 29 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via Digitalmars-d wrote:

 In nearly every benchmark I see D in, the default compiler used is dmd
 which runs computationally intense tasks 4-5x+ slower than GDC/LDC


As I keep saying, in my own compute-intensive projects I have
consistently found that dmd-generated code (dmd -O -inline -release) is
about 20-30% slower on average, sometimes even up to 50% slower,
compared to gdc-generated code (gdc -O3 -finline -frelease). This is
measured by actual running time in an actual application, not
benchmark-specific code.

I have looked at the generated assembly before, and it's clear that the
gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to
inline inner loop code after about 1-2 levels of function call nesting,
not to mention it's unable to factor out a lot of loop boilerplate code.

The gdc optimizer, by contrast, not only factors out almost all loop
boilerplate code and inlines inner loop function calls several levels
deep, it also unrolls loops in a CPU-specific way, does major loop
restructuring, compounded with much more linear code optimization than
dmd does, instruction reordering and then refactoring after that, etc.,
in some cases reducing the size of inner loop code (as in, the amount of
code that runs per iteration) by up to 90%.

I don't know the internal workings of the dmd optimizer, but it's clear
that at present, with almost nobody working on it except Walter, it's
never going to catch up. (Maybe this statement will provoke Walter into
working his magic? :-P)


[...]

 This isn't the first time I've seen this, in basically every benchmark
 featuring D I have to submit a patch/make a comment that dmd shouldn't
 be used. Make no mistake, this is damaging to D's reputation - how
 well does D's "native efficiency" go over when people are saying it's

 
 LDC and GDC need promoted more.


[...]

This will probably offend some people, but I think LDC/GDC should be the
default download on dlang.org, and dmd should be provided as an
alternative for those who want the latest language version and don't
mind the speed compromise.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before
which you fail to deliver after.
May 29 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 This will probably offend some people, but I think LDC/GDC 
 should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and 
 don't
 mind the speed compromise.


I did make LDC default compiler used in Arch but now people are 
unhappy with increased compile times so I may need to revert it 
back :)
May 29 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

This will probably offend some people, but I think LDC/GDC should be
the default download on dlang.org, and dmd should be provided as an
alternative for those who want the latest language version and don't
mind the speed compromise.


 
 I did make LDC default compiler used in Arch but now people are
 unhappy with increased compile times so I may need to revert it back
 :)


Can't please 'em all... According to Walter, many D users want fast
compile times, and aren't as concerned about performance of the
generated code. But from this thread's OP, it seems there's another
group of users who don't care about fast compile times but want the
generated code to squeeze every last drop of performance from their
CPUs.

So I guess we should be equally recommending all 3 compilers, with a
note to help people choose their compiler depending on their needs.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
May 29 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Friday, 29 May 2015 at 19:01:18 UTC, H. S. Teoh wrote:

 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via 
 Digitalmars-d wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

This will probably offend some people, but I think LDC/GDC 
should be
the default download on dlang.org, and dmd should be provided 
as an
alternative for those who want the latest language version 
and don't
mind the speed compromise.


 
 I did make LDC default compiler used in Arch but now people are
 unhappy with increased compile times so I may need to revert 
 it back
 :)


 Can't please 'em all... According to Walter, many D users want 
 fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's 
 another
 group of users who don't care about fast compile times but want 
 the
 generated code to squeeze every last drop of performance from 
 their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, 
 with a
 note to help people choose their compiler depending on their 
 needs.


 T


I think it might be worth investigating why LDC/GDC are slower 
than dmd when compiling non-optimized builds. This seems like 
something that would be easier to solve than getting dmd up to 
the same performance level as LDC/GDC.
Bye,
May 29 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 This will probably offend some people, but I think LDC/GDC should be
 the default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.


 I did make LDC default compiler used in Arch but now people are
 unhappy with increased compile times so I may need to revert it back
 :)


 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


myOpinion = (fastCompileTimes * 10000 < fastCode);

-Steve
May 29 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer 
wrote:

 On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via 
 Digitalmars-d wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 This will probably offend some people, but I think LDC/GDC 
 should be
 the default download on dlang.org, and dmd should be 
 provided as an
 alternative for those who want the latest language version 
 and don't
 mind the speed compromise.


 I did make LDC default compiler used in Arch but now people 
 are
 unhappy with increased compile times so I may need to revert 
 it back
 :)


 Can't please 'em all... According to Walter, many D users want 
 fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's 
 another
 group of users who don't care about fast compile times but 
 want the
 generated code to squeeze every last drop of performance from 
 their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, 
 with a
 note to help people choose their compiler depending on their 
 needs.


 myOpinion = (fastCompileTimes * 10000 < fastCode);

 -Steve


For the development cycle too?
May 29 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Friday, 29 May 2015 at 22:05:27 UTC, Idan Arye wrote:

 For the development cycle too?


I've had LDC edge out dmd in compilation times during development 
cycle. dmd sees zero boost from separate object compilation.

Using DCD as an example(because it has not-long not-short build 
times,)

initial non-optimized build took 3.10 elapsed with dmd, 5.11 with 
ldc.
Changing one file and building took the same amount for dmd but 
only 0.43 seconds(430 milliseconds) for ldc.

Bye,
May 29 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/29/15 4:05 PM, Idan Arye wrote:

 On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer wrote:

 On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d
 wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 This will probably offend some people, but I think LDC/GDC should be
 the default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.


 I did make LDC default compiler used in Arch but now people are
 unhappy with increased compile times so I may need to revert it back
 :)


 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


 myOpinion = (fastCompileTimes * 10000 < fastCode);


 For the development cycle too?


I saw the slide from Liran that shows your compiler requirements :) I 
can see why it's important to you.

But compiled code outlives the compiler execution. It's the wart that 
persists.

But techniques (for most projects) are available to speed compile time, 
and even in that case, compile time for whole project is quite low.

For very large projects, toolchain performance is definitely important. 
We need to work on that.

But I don't see how speed of compiler should sacrifice runtime performance.

-Steve
May 29 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 30/05/15 03:57, Steven Schveighoffer wrote:


 I saw the slide from Liran that shows your compiler requirements :) I
 can see why it's important to you.


Then you misunderstood Liran's slides.

Our compile resources problem isn't with GDC. It's with DMD. Single 
object compilation requires more RAM than most developers machines have, 
resulting in a complicated "rsync to AWS, run script there, compile, 
fetch results" cycle that adds quite a while to the compilation time.


THAT DOES NOT MATCH THE SOURCE.

I have not seen LDC myself, but according to Liran, situation there is 
even worse. The compiler simply does not finish compilation without 
crashing.

 But compiled code outlives the compiler execution. It's the wart that
 persists.


So does algorithmic code that, due to a compiler bugs, produces an 
assembly that does not implement the correct algorithm.

When doing RAID parity calculation, it is imperative that the correct 
bit gets to the correct location with the correct value. If that doesn't 
happen, compilation speed is the least of your problems.

Like Liran said in the lecture, we are currently faster than all of our 
competition. Still, in a correctly functioning storage system, the RAID 
part needs to take considerable amount of the total processing time 
under load (say, 30%). If we're losing x3 speed because we don't have 
compiler optimizations, the system, as a whole, is losing about half of 
its performance.


 But I don't see how speed of compiler should sacrifice runtime performance.


Our plan was to compile with DMD during the development stage, and then 
switch to GDC for code intended for deployment. This plan simply cannot 
work if each time we try and make that switch, Liran has to spend two 
months, each time yanking a different developer from the work said 
developer needs to be doing, in order to figure out which line of source 
gets compiled incorrectly.


 -Steve


Shachar
May 30 2015
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 May 2015 at 20:38, Shachar Shemesh via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 30/05/15 03:57, Steven Schveighoffer wrote:

  I saw the slide from Liran that shows your compiler requirements :) I

 can see why it's important to you.


 Then you misunderstood Liran's slides.

 Our compile resources problem isn't with GDC. It's with DMD. Single object
 compilation requires more RAM than most developers machines have, resulting
 in a complicated "rsync to AWS, run script there, compile, fetch results"
 cycle that adds quite a while to the compilation time.


 THAT DOES NOT MATCH THE SOURCE.


Got any bug reports to back that up?  I should probably run the testsuite
with optimisations turned on sometime.
May 30 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote:


 Got any bug reports to back that up?  I should probably run the
 testsuite with optimisations turned on sometime.


The latest one (the one that stung my code) is 
http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs 
opened by Liran are usually around that area, as he's the one who does 
the porting of our code to GDC.

Shachar
Jun 01 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 Jun 2015 09:25, "Shachar Shemesh via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote:


 Got any bug reports to back that up?  I should probably run the
 testsuite with optimisations turned on sometime.


 The latest one (the one that stung my code) is


http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs
opened by Liran are usually around that area, as he's the one who does the
porting of our code to GDC.

 Shachar


OK thanks, I'll try to mentally couple you two together.   I'm aware of the
bugs Liran has made.  There's just some 'very big things' going on which
has me away from bug fixing currently.
Jun 01 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/30/15 2:38 PM, Shachar Shemesh wrote:

 On 30/05/15 03:57, Steven Schveighoffer wrote:



 But I don't see how speed of compiler should sacrifice runtime
 performance.


 Our plan was to compile with DMD during the development stage, and then
 switch to GDC for code intended for deployment. This plan simply cannot
 work if each time we try and make that switch, Liran has to spend two
 months, each time yanking a different developer from the work said
 developer needs to be doing, in order to figure out which line of source
 gets compiled incorrectly.


You're answering a question that was not asked. Obviously, 
compiler-generated code should match what the source says. That's way 
more important than speed of compilation or speed of execution.

So given that a compiler actually *works* (i.e. produces valid 
binaries), is speed of compilation better than speed of execution of the 
resulting binary? How much is too much? And there are thresholds for 
things that really make the difference between works and not works. For 
instance, a requirement for 30GB of memory is not feasible for most 
systems. If you have to have 30GB of memory to compile, then the 
effective result is that compiler doesn't work. Similarly, if a compiler 
takes 2 weeks to output a binary, even if it's the fastest binary on the 
planet, that compiler doesn't work.

But if we are talking the difference between a compiler taking 10 
minutes to produce a binary that is 20% faster than a compiler that 
takes 1 minute, what is the threshold of pain you are willing to accept? 
My preference is for the 10 minute compile time to get the fastest 
binary. If it's possible to switch the compiler into "fast mode" that 
gives me a slower binary, I might use that for development.

My original statement was obviously exaggerated, I would not put up with 
days-long compile times, I'd find another way to do development. But 
compile time is not as important to me as it is to others.

-Steve
Jun 01 2015
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 01/06/15 18:40, Steven Schveighoffer wrote:

 On 5/30/15 2:38 PM, Shachar Shemesh wrote:

 So given that a compiler actually *works* (i.e. produces valid
 binaries), is speed of compilation better than speed of execution of the
 resulting binary?


There is no answer to that question.

During development stage, there are many steps that have "compile" as a 
hard start/end barrier (i.e. - you have to finish a task before compile 
start, and cannot continue it until compile ends). During those stages, 
the difference between 1 and 10 minute compile is the difference between 
1 and 10 bugs solved in a day. It is a huge difference, and one it is 
worth sacrificing any amount of run time efficiency to pay, assuming 
this is a tradeoff you can later make.

Then again, when a release build is being prepared, the difference 
becomes moot. Even your "outrageous" figures become acceptable, so long 
as you can be sure that no bugs pop up in this build that did not exist 
in the non-optimized build.

Then again, please bear in mind that our product is somewhat atypical. 
Most actual products in the market are not CPU bound on algorithmic 
code. When that's the case, the optimization stage (beyond the most 
basic inlining stuff) will rarely give you 20% overall speed increase. 
When your code performs a system call every 40 assembly instructions, 
there simply isn't enough room for the optimizer to work its magic.

One exception to that above rule is where it hurts. Benchmarks, 
typically, do rely on algorithmic code to a large extent.

Shachar
Jun 02 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 June 2015 at 19:42, Shachar Shemesh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 01/06/15 18:40, Steven Schveighoffer wrote:

 On 5/30/15 2:38 PM, Shachar Shemesh wrote:

 So given that a compiler actually *works* (i.e. produces valid
 binaries), is speed of compilation better than speed of execution of the
 resulting binary?


 There is no answer to that question.

 During development stage, there are many steps that have "compile" as a hard
 start/end barrier (i.e. - you have to finish a task before compile start,
 and cannot continue it until compile ends). During those stages, the
 difference between 1 and 10 minute compile is the difference between 1 and
 10 bugs solved in a day. It is a huge difference, and one it is worth
 sacrificing any amount of run time efficiency to pay, assuming this is a
 tradeoff you can later make.

 Then again, when a release build is being prepared, the difference becomes
 moot. Even your "outrageous" figures become acceptable, so long as you can
 be sure that no bugs pop up in this build that did not exist in the
 non-optimized build.

 Then again, please bear in mind that our product is somewhat atypical. Most
 actual products in the market are not CPU bound on algorithmic code. When
 that's the case, the optimization stage (beyond the most basic inlining
 stuff) will rarely give you 20% overall speed increase. When your code
 performs a system call every 40 assembly instructions, there simply isn't
 enough room for the optimizer to work its magic.

 One exception to that above rule is where it hurts. Benchmarks, typically,
 do rely on algorithmic code to a large extent.

 Shachar


Quality of optimisation is also proportional to battery consumption.
Even if the performance increase for a user isn't significant to them
in terms of responsiveness, it has an effect on their battery life,
which they do appreciate, even if they are unaware of it.
Jun 02 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer 
wrote:

 But if we are talking the difference between a compiler taking 
 10 minutes to produce a binary that is 20% faster than a 
 compiler that takes 1 minute, what is the threshold of pain you 
 are willing to accept? My preference is for the 10 minute 
 compile time to get the fastest binary. If it's possible to 
 switch the compiler into "fast mode" that gives me a slower 
 binary, I might use that for development.


Same here.
Jun 02 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer 
wrote:

 My original statement was obviously exaggerated, I would not 
 put up with days-long compile times, I'd find another way to do 
 development. But compile time is not as important to me as it 
 is to others.

 -Steve


I think if compile time was such a dealbreaker as people make it 
out to be, C++ would be a lot less popular.

I'm honestly in favor of making GDC the default compiler so I can 
have more coffee breaks ;)
Jun 02 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 02/06/15 21:56, weaselcat wrote:

 On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:

 My original statement was obviously exaggerated, I would not put up
 with days-long compile times, I'd find another way to do development.
 But compile time is not as important to me as it is to others.

 -Steve


 I think if compile time was such a dealbreaker as people make it out to
 be, C++ would be a lot less popular.


You know, I keep hearing this criticism. I have no idea where it comes from.

I can tell you in no uncertain words that a project the size we're 
working on would compile in considerably less time had it been written 
in C++.

If you are only referring to small projects, then compilation time isn't 
a major issue one way or the other.

Shachar
Jun 02 2015
parent reply "Dicebot" <public dicebot.lv> writes:
Project size is irrelevant here. I had 500 line C++ project that 
took 10 minutes to compile (hello boost::spirit). It is 
impossible for C++ to compile faster than D by design. Any time 
it seems so you either aren't comparing same thing or get 
misinformed. Or do straightforward separate compilation.
Jun 03 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project 
 that took 10 minutes to compile (hello boost::spirit). It is 
 impossible for C++ to compile faster than D by design. Any time 
 it seems so you either aren't comparing same thing or get 
 misinformed. Or do straightforward separate compilation.


Even C.

Our project, back when I was doing C in the early 2000's, a "make 
clean all" took around one hour.
Jun 03 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo  Pinto wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project 
 that took 10 minutes to compile (hello boost::spirit). It is 
 impossible for C++ to compile faster than D by design. Any 
 time it seems so you either aren't comparing same thing or get 
 misinformed. Or do straightforward separate compilation.


 Even C.


Now really? C was designed at a time where you couldn't even hold 
the source file in memory, so there is not even a need for an 
explicit AST.

C can essentially be "streamed" in separate passes: 
cpp->cc->asm->linking

If compiling C is slow, it is just the compiler or the build 
system, not the language.
Jun 03 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 3 June 2015 at 10:37:24 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo  Pinto wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project 
 that took 10 minutes to compile (hello boost::spirit). It is 
 impossible for C++ to compile faster than D by design. Any 
 time it seems so you either aren't comparing same thing or 
 get misinformed. Or do straightforward separate compilation.


 Even C.


 Now really? C was designed at a time where you couldn't even 
 hold the source file in memory, so there is not even a need for 
 an explicit AST.

 C can essentially be "streamed" in separate passes: 
 cpp->cc->asm->linking

 If compiling C is slow, it is just the compiler or the build 
 system, not the language.


Yes really, specially when comparing with Turbo Pascal, Delphi, 
Modula-2, Oberon and a few other languages not tied to UNIX 
linker model.

Multiply that hour times HP-UX (aCC), Solaris (SunPro), Windows 
(cl), Aix (xlc), Red-Hat Linux (gcc). Which were the systems 
being used.

As a side note, Visual C++ 2015 will be quite fast.

http://channel9.msdn.com/Events/Build/2015/3-610

They literal have re-done their linker to use a database model 
and support incremental linking.

Similarly to what IBM did with Visual C++ Code Store and Lucid's 
Energize.

All the solutions have in common not relying in the traditional 
UNIX linker model.


--
Paulo
Jun 03 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 12:20:29 UTC, Paulo  Pinto wrote:

 Yes really, specially when comparing with Turbo Pascal, Delphi, 
 Modula-2, Oberon and a few other languages not tied to UNIX 
 linker model.


Yeah, I agree that the implementation for Turbo Pascal was good 
for the hardware it ran on. But I don't think Pascal as a 
language is easier to compile fast than C. I think they match up.


 As a side note, Visual C++ 2015 will be quite fast.

 http://channel9.msdn.com/Events/Build/2015/3-610

 They literal have re-done their linker to use a database model 
 and support incremental linking.


Ok, I don't view linking as part of compilation... I don't think 
C as a language requires a specific linkage model (only the 
conceptual compilation units).
Jun 03 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 12:20:28 +0000, Paulo  Pinto wrote:


 Now really? C was designed at a time where you couldn't even hold the
 source file in memory, so there is not even a need for an explicit AST.

 C can essentially be "streamed" in separate passes:
 cpp->cc->asm->linking

 If compiling C is slow, it is just the compiler or the build system,
 not the language.


=20
 Yes really, specially when comparing with Turbo Pascal, Delphi,
 Modula-2, Oberon and a few other languages not tied to UNIX linker
 model.


yes, i remember lightning fast compile times with turbo pascal. yet the=20
code it produced was really awful: it was even unable to fold constants=20
sometimes!=
Jun 03 2015
next sibling parent Dan Olson <gorox comcast.net> writes:
ketmar <ketmar ketmar.no-ip.org> writes:


 yes, i remember lightning fast compile times with turbo pascal. yet the 
 code it produced was really awful: it was even unable to fold constants 
 sometimes!


I remember it being in a single DOS .COM (was it TURBO.COM?) only about
40k which included the editor, compiler, and libraries.  It was the
coolest thing for PC's at the time.  I might even have a floppy with it
on it :-)
Jun 03 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 4 June 2015 at 03:04:31 UTC, ketmar wrote:

 On Wed, 03 Jun 2015 12:20:28 +0000, Paulo  Pinto wrote:


 Now really? C was designed at a time where you couldn't even 
 hold the
 source file in memory, so there is not even a need for an 
 explicit AST.

 C can essentially be "streamed" in separate passes:
 cpp->cc->asm->linking

 If compiling C is slow, it is just the compiler or the build 
 system,
 not the language.


 
 Yes really, specially when comparing with Turbo Pascal, Delphi,
 Modula-2, Oberon and a few other languages not tied to UNIX 
 linker
 model.


 yes, i remember lightning fast compile times with turbo pascal. 
 yet the
 code it produced was really awful: it was even unable to fold 
 constants
 sometimes!


No different from other MS-DOS C compilers.

Hence why such languages were the Pythons and Rubys of the day
and anyone that cared about performance was using straight
Assembly, in MS-DOS and other home systems, that is.

Michael Abrash books The Zen of Assembly Language and  Zen of
Code Optimization were published in 1990 and 1994 respectively.

--
Paulo
Jun 04 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-06-03 12:37, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Now really? C was designed at a time where you couldn't even hold the
 source file in memory, so there is not even a need for an explicit AST.

 C can essentially be "streamed" in separate passes: cpp->cc->asm->linking

 If compiling C is slow, it is just the compiler or the build system, not
 the language.


Doesn't a C compiler need to reparse headers in C? Unlike D were they 
can be cached.

-- 
/Jacob Carlborg
Jun 04 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/3/15 3:50 AM, Paulo Pinto wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project that took
 10 minutes to compile (hello boost::spirit). It is impossible for C++
 to compile faster than D by design. Any time it seems so you either
 aren't comparing same thing or get misinformed. Or do straightforward
 separate compilation.


 Even C.

 Our project, back when I was doing C in the early 2000's, a "make clean
 all" took around one hour.


It might be possible the processor/RAM constraints were different in 
2000 than they are now :)

-Steve
Jun 03 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer 
wrote:

 On 6/3/15 3:50 AM, Paulo Pinto wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project 
 that took
 10 minutes to compile (hello boost::spirit). It is impossible 
 for C++
 to compile faster than D by design. Any time it seems so you 
 either
 aren't comparing same thing or get misinformed. Or do 
 straightforward
 separate compilation.


 Even C.

 Our project, back when I was doing C in the early 2000's, a 
 "make clean
 all" took around one hour.


 It might be possible the processor/RAM constraints were 
 different in 2000 than they are now :)

 -Steve


Yeah, some people take 9 hours instead with C++ using modern 
hardware.

http://www.reddit.com/r/programming/comments/37n39g/john_carmack_shares_his_experiences_with_static/croml2i

If you noticed a later post from me, those systems were UNIX 
servers, not desktop PCs.

--
Paulo
Jun 03 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/3/15 10:19 AM, Paulo Pinto wrote:

 On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer wrote:

 On 6/3/15 3:50 AM, Paulo Pinto wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 Project size is irrelevant here. I had 500 line C++ project that took
 10 minutes to compile (hello boost::spirit). It is impossible for C++
 to compile faster than D by design. Any time it seems so you either
 aren't comparing same thing or get misinformed. Or do straightforward
 separate compilation.


 Even C.

 Our project, back when I was doing C in the early 2000's, a "make clean
 all" took around one hour.


 It might be possible the processor/RAM constraints were different in
 2000 than they are now :)


 Yeah, some people take 9 hours instead with C++ using modern hardware.

 http://www.reddit.com/r/programming/comments/37n39g/john_carmack_shares_his_experiences_with_static/croml2i


 If you noticed a later post from me, those systems were UNIX servers,
 not desktop PCs.


Sure, but I still think it's difficult to compare systems. Processors 
just weren't that fast back then. You could have 256 of them, and lots 
of RAM, but the RAM architecture was slower too.

If your compiler could run in parallel to build, perhaps you could get 
faster compile times, but it's so difficult to compare these things in 
an apples-to-apples comparison. Especially when the size/complexity of 
the program being compiled isn't necessarily analogous.

-Steve
Jun 03 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 It is impossible for C++ to compile faster than D by design. 
 Any time it seems so you either aren't comparing same thing or 
 get misinformed. Or do straightforward separate compilation.


There are lots of features in D, that C++ does not have, that 
will make separate compilation and partial evaluation/incomplete 
types difficult. So C++ is faster than D by design, even when the 
compiler isn't.

The same features that many think are great about D are also the 
ones that makes formal reasoning about isolated parts of a D 
program difficult or impossible. You surely don't need a list?
Jun 03 2015
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 There are lots of features in D, that C++ does not have, that 
 will make separate compilation and partial 
 evaluation/incomplete types difficult. So C++ is faster than D 
 by design, even when the compiler isn't.


I've tried to parse that last sentence a few times and I'm not 
sure what you mean. A theoretical compiler doesn't matter; what 
actual compilers do does. The empirical fact is that C++ is 
slower to compile than D (AFAIK C++ compiles slower than 
everything that isn't Scala). If you have a benchmarch that shows 
C++ compiling faster than D, please share it.

Atila
Jun 03 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
 sure what you mean. A theoretical compiler doesn't matter; what 
 actual compilers do does.


Of course it does, it defines how far you can go in a concurrent 
build process before hitting an unsurpassable bottle-neck.

(not that I personally care, as I find both C++ and D compilers 
to be fast enough)
Jun 03 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 3 June 2015 at 09:21:55 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:

 It is impossible for C++ to compile faster than D by design. 
 Any time it seems so you either aren't comparing same thing or 
 get misinformed. Or do straightforward separate compilation.


 There are lots of features in D, that C++ does not have, that 
 will make separate compilation and partial 
 evaluation/incomplete types difficult. So C++ is faster than D 
 by design, even when the compiler isn't.


LDC seems to manage separate compilation just fine, I use it for 
my projects at least. in my tests I find it to be 110-150% faster 
than all at once.

it can get even better if you properly modularize your projects 
instead of having 1-2 files that build slow, which causes a lot 
of waiting.
Jun 03 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:

 it can get even better if you properly modularize your projects 
 instead of having 1-2 files that build slow, which causes a lot 
 of waiting.


Yes, sure. You can probably get the same build speeds as with C 
if you organize your code in a particular way or shy away from 
certain patterns.

What I was talking about was the language, meaning that you don't 
write your code to give a boost in compilation speed. Clearly 
possible, but if you use third party frameworks… then you're out 
of luck.

An analogy: SQL isn't particularly expressive, but the 
limitations of the language makes it possible to execute it 
bottom-up. NOSQL engines are even less expressive, but can be 
even more easily distributed.
Jun 03 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:

 it can get even better if you properly modularize your 
 projects instead of having 1-2 files that build slow, which 
 causes a lot of waiting.


 Yes, sure. You can probably get the same build speeds as with C 
 if you organize your code in a particular way or shy away from 
 certain patterns.

 What I was talking about was the language, meaning that you 
 don't write your code to give a boost in compilation speed. 
 Clearly possible, but if you use third party frameworks… then 
 you're out of luck.

 An analogy: SQL isn't particularly expressive, but the 
 limitations of the language makes it possible to execute it 
 bottom-up. NOSQL engines are even less expressive, but can be 
 even more easily distributed.


ah yes, those famous fast C build times.
Excuse me while I go take half an hour to build GDB.
Jun 03 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 11:35:43 UTC, weaselcat wrote:

 ah yes, those famous fast C build times.
 Excuse me while I go take half an hour to build GDB.


Heh... It is possible to write very fast C compilers with high 
concurrency in builds, if there is a market for it, but most 
people want some optimizations too. So that's what people 
evaluate a compiler by: typical integration builds. Squeaky wheel 
gets most oil.
Jun 03 2015
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 June 2015 at 13:35, weaselcat via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Gr=C3=B8stad wrote=


:

 On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:


 it can get even better if you properly modularize your projects instead
 of having 1-2 files that build slow, which causes a lot of waiting.


 Yes, sure. You can probably get the same build speeds as with C if you
 organize your code in a particular way or shy away from certain patterns=




.

 What I was talking about was the language, meaning that you don't write
 your code to give a boost in compilation speed. Clearly possible, but if
 you use third party frameworks=E2=80=A6 then you're out of luck.

 An analogy: SQL isn't particularly expressive, but the limitations of th=




e

 language makes it possible to execute it bottom-up. NOSQL engines are ev=




en

 less expressive, but can be even more easily distributed.


 ah yes, those famous fast C build times.
 Excuse me while I go take half an hour to build GDB.


You're probably doing it wrong and accidentally building all of binutils
instead.  Use 'make all-gdb' and enjoy faster builds :-p
Jun 03 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 June 2015 at 15:14:47 UTC, Iain Buclaw wrote:

 You're probably doing it wrong and accidentally building all of 
 binutils
 instead.  Use 'make all-gdb' and enjoy faster builds :-p


Or use TCC. :^P
Jun 03 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 11:35:41 +0000, weaselcat wrote:


 On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Gr=C3=B8stad wrote=


:

 On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:

 it can get even better if you properly modularize your projects
 instead of having 1-2 files that build slow, which causes a lot of
 waiting.


 Yes, sure. You can probably get the same build speeds as with C if you
 organize your code in a particular way or shy away from certain
 patterns.

 What I was talking about was the language, meaning that you don't write
 your code to give a boost in compilation speed. Clearly possible, but
 if you use third party frameworks=E2=80=A6 then you're out of luck.

 An analogy: SQL isn't particularly expressive, but the limitations of
 the language makes it possible to execute it bottom-up. NOSQL engines
 are even less expressive, but can be even more easily distributed.


=20
 ah yes, those famous fast C build times.
 Excuse me while I go take half an hour to build GDB.


yet gcc (the C compiler part) is significantly faster than gdc on my box=20
(both gcc and gdc are built from sources, tuned to my arch). i mean=20
separate compilation, of course. i believe it's due to phobos.=
Jun 03 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:


 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d
 wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

This will probably offend some people, but I think LDC/GDC should be
the default download on dlang.org, and dmd should be provided as an
alternative for those who want the latest language version and don't
mind the speed compromise.


=20
 I did make LDC default compiler used in Arch but now people are unhappy
 with increased compile times so I may need to revert it back :)


=20
 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.
=20
 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


the thing is that benchmarks are measuring execution time, not compiling=20
time. that's why D is failing benchmarks. making LDC or GDC a "reference"=20
compiler, and stating that if someone is ready to trade codegen quality=20
for compilation speed, he can use DMD instead, is the way to start being=20
"benchmark friendly".

people doing benchmarks usually downloading what official site gives 'em.=20
so they taking DMD and assuming that it's the best *execution* speed D=20
can offer.

i.e. developers can continue using DMD as their base, but offering it as=20
"experimental compiler not recommended to use in production" on the=20
offsite, replacing "download D compiler" links with LDC/GDC. this way=20
people will not get Hot New Features right away, but "D is sloooow" rants=20
will go down. ;-)=
May 29 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 May 2015 at 09:14, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:


 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d
 wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

This will probably offend some people, but I think LDC/GDC should be
the default download on dlang.org, and dmd should be provided as an
alternative for those who want the latest language version and don't
mind the speed compromise.


 I did make LDC default compiler used in Arch but now people are unhappy
 with increased compile times so I may need to revert it back :)


 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


 the thing is that benchmarks are measuring execution time, not compiling
 time. that's why D is failing benchmarks. making LDC or GDC a "reference"
 compiler, and stating that if someone is ready to trade codegen quality
 for compilation speed, he can use DMD instead, is the way to start being
 "benchmark friendly".

 people doing benchmarks usually downloading what official site gives 'em.
 so they taking DMD and assuming that it's the best *execution* speed D
 can offer.

 i.e. developers can continue using DMD as their base, but offering it as
 "experimental compiler not recommended to use in production" on the
 offsite, replacing "download D compiler" links with LDC/GDC. this way
 people will not get Hot New Features right away, but "D is sloooow" rants
 will go down. ;-)


I actually think this is a really good idea. I don't think it's right
that random people should encounter DMD as a first impression, they
should encounter GDC or LDC, since those are the toolsets they will be
making direct comparisons against during their evaluation. At the
point that they're not yet a D enthusiast, access to cutting edge
language features should mean practically nothing to them.

That said, it would be nice if the DMD developer community at large
were able to work closer with GDC/LDC. Is there some changes in
workflow that may keep GDC/LDC up to date beside DMD as PR's are
added? Possible to produce 'nightlies' for those compilers, so that
developers following mainline DMD can easily update their respective
compilers to reflect? Perhaps DMD developers could even develop
language features against LDC instead of DMD, and backport to DMD?

For my work, and what I noticed in my other thread, is that LDC is
central to expansion of the D ecosystem, and I think it needs to be
taken more seriously by the entire DMD community; it can't be a little
thing off to the side.
LDC gives us portability; iOS, Android, Windows, Emscripten,
NativeClient, and plenty of other platforms. It's 2015; the fact that
we still don't support Android and iOS is just not unacceptable. Most
computers in the world run those operating systems. LDC is also the
only performant way to target Windows, the overwhelmingly largest
desktop platform... but we lose the debugger! >_<
How can we release products created with D if we still don't have a
way to build and run on modern computers?

So, LDC: Windows, Android, iOS... this must be 99.9999% of computers
on the planet! LDC needs to be first-class. Ideally, even more
polished than DMD, and it should probably be the first contact people
have with D.

* I don't mean to down-play GDC, but it can't give us Windows or iOS,
which are critical targets.


I want to use D in my work, right now. I could... if I could actually
target the computers we run code on.
May 29 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:


 * I don't mean to down-play GDC, but it can't give us Windows or iOS,
 which are critical targets.


just to note: ARM is supported in GDC (althru i never tested that support=20
myself), and there are semi-official windows builds of GDC.

so GDC can give us windows support (it's simply not required by many GDC=20
users for the time), but this is relatively easy to fix.

dunno about iOS specifics, but if LDC has some druntime fixes for that,=20
such fixes can be integrated in mainline, and GDC should be able to build=20
ARM binaries for that apple thingy.=
May 29 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 May 2015 05:25, "ketmar via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:


 * I don't mean to down-play GDC, but it can't give us Windows or iOS,
 which are critical targets.


 just to note: ARM is supported in GDC (althru i never tested that support
 myself), and there are semi-official windows builds of GDC.

 so GDC can give us windows support (it's simply not required by many GDC
 users for the time), but this is relatively easy to fix.


When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI (at least I see no motivation as of writing).
May 30 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:

 When he says Windows, he means MSVC, gcc backend will never support
 interfacing that ABI (at least I see no motivation as of writing).


I thought that's what MINGW was. A gcc backend that interfaces with the 
Windows ABI. Isn't it?

Shachar
May 30 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:

 When he says Windows, he means MSVC, gcc backend will never support
 interfacing that ABI (at least I see no motivation as of writing).


 I thought that's what MINGW was. A gcc backend that interfaces with the
 Windows ABI. Isn't it?


If your program is isolated, MinGW is fine. Great even!
But the Windows ecosystem is built around Microsoft's COFF formatted
libraries (as produced by Visual Studio), and most Windows libs that I
find myself working with are closed-source, or distributed as
pre-built binaries.
You can't do very large scale work in the Windows ecosystem without
interacting with the MS ecosystem, that is, COFF libs, and CV8/PDB
debuginfo.

Even if we could use MinGW, we ship an SDK ourselves, and customers
would demand COFF libs from us.
LLVM is (finally!) addressing this Microsoft/VisualC-centric nature of
the Windows dev environment... I just wish they'd hurry up! It's about
10 years overdue.
May 30 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 31/05/15 02:08, Manu via Digitalmars-d wrote:

 On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:

 When he says Windows, he means MSVC, gcc backend will never support
 interfacing that ABI (at least I see no motivation as of writing).


 I thought that's what MINGW was. A gcc backend that interfaces with the
 Windows ABI. Isn't it?


 If your program is isolated, MinGW is fine. Great even!
 But the Windows ecosystem is built around Microsoft's COFF formatted
 libraries (as produced by Visual Studio), and most Windows libs that I
 find myself working with are closed-source, or distributed as
 pre-built binaries.


Again, sorry for my ignorance. I just always assumed that the main 
difference between mingw and cygwin is precisely that: that mingw 
executables are PE formatted, and can import PE DLLs (such as the Win32 
DLLs themselves).

If that is not the case, what is the mingw format? How does it allow you 
to link in the Win32 DLLs if it does not support COFF?

Shachar
May 31 2015
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 31/05/15 02:08, Manu via Digitalmars-d wrote:

 On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:

 When he says Windows, he means MSVC, gcc backend will never support
 interfacing that ABI (at least I see no motivation as of writing).


 I thought that's what MINGW was. A gcc backend that interfaces with the
 Windows ABI. Isn't it?



 If your program is isolated, MinGW is fine. Great even!
 But the Windows ecosystem is built around Microsoft's COFF formatted
 libraries (as produced by Visual Studio), and most Windows libs that I
 find myself working with are closed-source, or distributed as
 pre-built binaries.


 Again, sorry for my ignorance. I just always assumed that the main
 difference between mingw and cygwin is precisely that: that mingw
 executables are PE formatted, and can import PE DLLs (such as the Win32 DLLs
 themselves).

 If that is not the case, what is the mingw format? How does it allow you to
 link in the Win32 DLLs if it does not support COFF?

 Shachar


I did once play with a coff mingw build, but I think the key issue I
had there was the C runtime. GCC built code seems to produce intrinsic
calls to glibc, and it is incompatible with MSVCRT.
I'm pretty certain that GCC can't emit code to match the Win32
exception model, and there's still the debuginfo data to worry about
too.
May 31 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 May 2015 at 10:45, Manu via Digitalmars-d <digitalmars-d puremagic.com

 wrote:



 On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 31/05/15 02:08, Manu via Digitalmars-d wrote:

 On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:

 When he says Windows, he means MSVC, gcc backend will never support
 interfacing that ABI (at least I see no motivation as of writing).


 I thought that's what MINGW was. A gcc backend that interfaces with the
 Windows ABI. Isn't it?



 If your program is isolated, MinGW is fine. Great even!
 But the Windows ecosystem is built around Microsoft's COFF formatted
 libraries (as produced by Visual Studio), and most Windows libs that I
 find myself working with are closed-source, or distributed as
 pre-built binaries.


 Again, sorry for my ignorance. I just always assumed that the main
 difference between mingw and cygwin is precisely that: that mingw
 executables are PE formatted, and can import PE DLLs (such as the Win32


 DLLs

 themselves).

 If that is not the case, what is the mingw format? How does it allow you


 to

 link in the Win32 DLLs if it does not support COFF?

 Shachar


 I did once play with a coff mingw build, but I think the key issue I
 had there was the C runtime. GCC built code seems to produce intrinsic
 calls to glibc, and it is incompatible with MSVCRT.
 I'm pretty certain that GCC can't emit code to match the Win32
 exception model, and there's still the debuginfo data to worry about
 too.


Pretty much correct as far as I understand it.

- GCC uses DWARF to embed debug information into the program, rather that
store it in a separate PDB.
- GCC uses SJLJ exceptions in C++ that work to it's own libunwind model.
- GCC uses Itanium C++ mangling, so mixed MSVC/G++ is a no-go.
- GCC uses cdecl as the default calling convention (need to double check
this is correct though).

That said, GCC does produce a COFF binary that is understood by the Windows
platform (otherwise you wouldn't be able to run programs).  But interacting
with Windows libraries is restricted to the lowest API, that being anything
that was marked with stdcall, fastcall or cdecl.

MinGW is an entriely isolated runtime environment that fills the
missing/incompatible gaps between Windows and GNU/Posix runtime to allows
GCC built programs to run.
May 31 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 30/05/2015 1:43 p.m., Manu via Digitalmars-d wrote:

 On 30 May 2015 at 09:14, ketmar via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:


 On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d
 wrote:

 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 This will probably offend some people, but I think LDC/GDC should be
 the default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.


 I did make LDC default compiler used in Arch but now people are unhappy
 with increased compile times so I may need to revert it back :)


 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


 the thing is that benchmarks are measuring execution time, not compiling
 time. that's why D is failing benchmarks. making LDC or GDC a "reference"
 compiler, and stating that if someone is ready to trade codegen quality
 for compilation speed, he can use DMD instead, is the way to start being
 "benchmark friendly".

 people doing benchmarks usually downloading what official site gives 'em.
 so they taking DMD and assuming that it's the best *execution* speed D
 can offer.

 i.e. developers can continue using DMD as their base, but offering it as
 "experimental compiler not recommended to use in production" on the
 offsite, replacing "download D compiler" links with LDC/GDC. this way
 people will not get Hot New Features right away, but "D is sloooow" rants
 will go down. ;-)


 I actually think this is a really good idea. I don't think it's right
 that random people should encounter DMD as a first impression, they
 should encounter GDC or LDC, since those are the toolsets they will be
 making direct comparisons against during their evaluation. At the
 point that they're not yet a D enthusiast, access to cutting edge
 language features should mean practically nothing to them.

 That said, it would be nice if the DMD developer community at large
 were able to work closer with GDC/LDC. Is there some changes in
 workflow that may keep GDC/LDC up to date beside DMD as PR's are
 added? Possible to produce 'nightlies' for those compilers, so that
 developers following mainline DMD can easily update their respective
 compilers to reflect? Perhaps DMD developers could even develop
 language features against LDC instead of DMD, and backport to DMD?

 For my work, and what I noticed in my other thread, is that LDC is
 central to expansion of the D ecosystem, and I think it needs to be
 taken more seriously by the entire DMD community; it can't be a little
 thing off to the side.
 LDC gives us portability; iOS, Android, Windows, Emscripten,
 NativeClient, and plenty of other platforms. It's 2015; the fact that
 we still don't support Android and iOS is just not unacceptable. Most
 computers in the world run those operating systems. LDC is also the
 only performant way to target Windows, the overwhelmingly largest
 desktop platform... but we lose the debugger! >_<
 How can we release products created with D if we still don't have a
 way to build and run on modern computers?

 So, LDC: Windows, Android, iOS... this must be 99.9999% of computers
 on the planet! LDC needs to be first-class. Ideally, even more
 polished than DMD, and it should probably be the first contact people
 have with D.

 * I don't mean to down-play GDC, but it can't give us Windows or iOS,
 which are critical targets.


 I want to use D in my work, right now. I could... if I could actually
 target the computers we run code on.


Both you and ketmer are evil.
I'm liking these ideas...

Now we just need some pretty and nice packages for e.g. Windows for ldc 
with debugger full support and we will be good.
Last time I looked llvm still needs a lot of work for Windows 
unfortunately. It may be time to direct some people to help them out ;)
May 29 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:

 Both you and ketmer are evil.
 I'm liking these ideas...

 Now we just need some pretty and nice packages for e.g. Windows 
 for ldc with debugger full support and we will be good.
 Last time I looked llvm still needs a lot of work for Windows 
 unfortunately. It may be time to direct some people to help 
 them out ;)


LDC seemed to work for the author of the blog on windows after 
fixing a path issue. After a quick look in the LDC NG, it seems 
to be mostly(?) working.

It feels like GDC/LDC are fragmented from the main D community 
which isn't good due to an already not-so-large community. 
Outside of manually going to check their issue trackers it's hard 
to know what's going on with them.

Bye,
May 29 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 30/05/2015 3:36 p.m., weaselcat wrote:

 On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:

 Both you and ketmer are evil.
 I'm liking these ideas...

 Now we just need some pretty and nice packages for e.g. Windows for
 ldc with debugger full support and we will be good.
 Last time I looked llvm still needs a lot of work for Windows
 unfortunately. It may be time to direct some people to help them out ;)


 LDC seemed to work for the author of the blog on windows after fixing a
 path issue. After a quick look in the LDC NG, it seems to be mostly(?)
 working.

 It feels like GDC/LDC are fragmented from the main D community which
 isn't good due to an already not-so-large community. Outside of manually
 going to check their issue trackers it's hard to know what's going on
 with them.

 Bye,


Even as of a few months ago LLVM wasn't fully working on 64bit Windows.
The llvm debugger had a long way to go for it.

So hopefully its come along way since then :)
May 29 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 May 2015 1:41 pm, "weaselcat via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:

 Both you and ketmer are evil.
 I'm liking these ideas...

 Now we just need some pretty and nice packages for e.g. Windows for ldc




with debugger full support and we will be good.

 Last time I looked llvm still needs a lot of work for Windows




unfortunately. It may be time to direct some people to help them out ;)

 LDC seemed to work for the author of the blog on windows after fixing a


path issue. After a quick look in the LDC NG, it seems to be mostly(?)
working.

There's a big difference between compiling a few lines of code, and
building a project with particular requirements, dependencies on various
foreign libs, cross language linkage, etc.

Ldc does a valiant effort, but there are still quite a lot of gaps.
I can't hold that against them, the whole dmd community needs to take
gdc/ldc as first class considerations.
May 30 2015
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
I'm having a pretty good experience with win64 ldc lately. Obviously the
fact that there's no debug info is a gigantic hole.

I have a hack environment where I dmd in debug and ldc for release builds,
but it's really not ideal. And you're limited to code that doesn't expose
bugs in both compilers.

The biggest problem I have with ldc, is that lots of normal compiler errors
pop up an ICE instead of a normal error message.
On 30 May 2015 1:26 pm, "Rikki Cattermole via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:


 On 30/05/2015 1:43 p.m., Manu via Digitalmars-d wrote:


 On 30 May 2015 at 09:14, ketmar via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:


 On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:

  On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d

 wrote:


 On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:


 This will probably offend some people, but I think LDC/GDC should be
 the default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.


 I did make LDC default compiler used in Arch but now people are unhappy
 with increased compile times so I may need to revert it back :)


 Can't please 'em all... According to Walter, many D users want fast
 compile times, and aren't as concerned about performance of the
 generated code. But from this thread's OP, it seems there's another
 group of users who don't care about fast compile times but want the
 generated code to squeeze every last drop of performance from their
 CPUs.

 So I guess we should be equally recommending all 3 compilers, with a
 note to help people choose their compiler depending on their needs.


 the thing is that benchmarks are measuring execution time, not compiling
 time. that's why D is failing benchmarks. making LDC or GDC a "reference"
 compiler, and stating that if someone is ready to trade codegen quality
 for compilation speed, he can use DMD instead, is the way to start being
 "benchmark friendly".

 people doing benchmarks usually downloading what official site gives 'em.
 so they taking DMD and assuming that it's the best *execution* speed D
 can offer.

 i.e. developers can continue using DMD as their base, but offering it as
 "experimental compiler not recommended to use in production" on the
 offsite, replacing "download D compiler" links with LDC/GDC. this way
 people will not get Hot New Features right away, but "D is sloooow" rants
 will go down. ;-)


 I actually think this is a really good idea. I don't think it's right
 that random people should encounter DMD as a first impression, they
 should encounter GDC or LDC, since those are the toolsets they will be
 making direct comparisons against during their evaluation. At the
 point that they're not yet a D enthusiast, access to cutting edge
 language features should mean practically nothing to them.

 That said, it would be nice if the DMD developer community at large
 were able to work closer with GDC/LDC. Is there some changes in
 workflow that may keep GDC/LDC up to date beside DMD as PR's are
 added? Possible to produce 'nightlies' for those compilers, so that
 developers following mainline DMD can easily update their respective
 compilers to reflect? Perhaps DMD developers could even develop
 language features against LDC instead of DMD, and backport to DMD?

 For my work, and what I noticed in my other thread, is that LDC is
 central to expansion of the D ecosystem, and I think it needs to be
 taken more seriously by the entire DMD community; it can't be a little
 thing off to the side.
 LDC gives us portability; iOS, Android, Windows, Emscripten,
 NativeClient, and plenty of other platforms. It's 2015; the fact that
 we still don't support Android and iOS is just not unacceptable. Most
 computers in the world run those operating systems. LDC is also the
 only performant way to target Windows, the overwhelmingly largest
 desktop platform... but we lose the debugger! >_<
 How can we release products created with D if we still don't have a
 way to build and run on modern computers?

 So, LDC: Windows, Android, iOS... this must be 99.9999% of computers
 on the planet! LDC needs to be first-class. Ideally, even more
 polished than DMD, and it should probably be the first contact people
 have with D.

 * I don't mean to down-play GDC, but it can't give us Windows or iOS,
 which are critical targets.


 I want to use D in my work, right now. I could... if I could actually
 target the computers we run code on.


 Both you and ketmer are evil.
 I'm liking these ideas...

 Now we just need some pretty and nice packages for e.g. Windows for ldc
 with debugger full support and we will be good.
 Last time I looked llvm still needs a lot of work for Windows
 unfortunately. It may be time to direct some people to help them out ;)
May 29 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 30 May 2015 at 04:01:00 UTC, Manu wrote:

 I'm having a pretty good experience with win64 ldc lately. 
 Obviously the
 fact that there's no debug info is a gigantic hole.

 I have a hack environment where I dmd in debug and ldc for 
 release builds,
 but it's really not ideal. And you're limited to code that 
 doesn't expose
 bugs in both compilers.


Does it generate any debug info at all, or does it just lack PDB 
debug info?
If the former, have you tried visualGDB with it(assuming you're 
using VS)?

Just a guess, I don't use windows. : )
May 29 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via 
 Digitalmars-d wrote:

 In nearly every benchmark I see D in, the default compiler 
 used is dmd
 which runs computationally intense tasks 4-5x+ slower than 
 GDC/LDC


 As I keep saying, in my own compute-intensive projects I have
 consistently found that dmd-generated code (dmd -O -inline 
 -release) is
 about 20-30% slower on average, sometimes even up to 50% slower,
 compared to gdc-generated code (gdc -O3 -finline -frelease). 
 This is
 measured by actual running time in an actual application, not
 benchmark-specific code.

 I have looked at the generated assembly before, and it's clear 
 that the
 gdc optimizer is way ahead of dmd's. The dmd optimizer starts 
 failing to
 inline inner loop code after about 1-2 levels of function call 
 nesting,
 not to mention it's unable to factor out a lot of loop 
 boilerplate code.

 The gdc optimizer, by contrast, not only factors out almost all 
 loop
 boilerplate code and inlines inner loop function calls several 
 levels
 deep, it also unrolls loops in a CPU-specific way, does major 
 loop
 restructuring, compounded with much more linear code 
 optimization than
 dmd does, instruction reordering and then refactoring after 
 that, etc.,
 in some cases reducing the size of inner loop code (as in, the 
 amount of
 code that runs per iteration) by up to 90%.

 I don't know the internal workings of the dmd optimizer, but 
 it's clear
 that at present, with almost nobody working on it except 
 Walter, it's
 never going to catch up. (Maybe this statement will provoke 
 Walter into
 working his magic? :-P)


dmd's backend is also under a proprietary license reducing the 
amount of people willing to contribute.
Not to mention that GDC and LDC benefit heavily from GCC and LLVM 
respectively, these aren't exactly one man projects(e.g, Google, 
Redhat, Intel, AMD etc contribute heavily to GCC and LLVM is 
basically Apple's baby.)


 [...]

 This isn't the first time I've seen this, in basically every 
 benchmark
 featuring D I have to submit a patch/make a comment that dmd 
 shouldn't
 be used. Make no mistake, this is damaging to D's reputation - 
 how
 well does D's "native efficiency" go over when people are 
 saying it's

 
 LDC and GDC need promoted more.


 [...]

 This will probably offend some people, but I think LDC/GDC 
 should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and 
 don't
 mind the speed compromise.


 T


I think they probably should be if only for the licensing issues, 
dmd can't even be redistributed - AFAIK it's in very, very few D 
repositories on Linux.


re dicebot:


I did make LDC default compiler used in Arch but now people are 
unhappy with increased compile times so I may need to revert it 
back :)


Maybe this should be brought up on LDC's issue tracker(that is, 
slower compilation times compared to dmd.)
Although it might have already been discussed.
May 29 2015
next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote:

 Maybe this should be brought up on LDC's issue tracker(that is, 
 slower compilation times compared to dmd.)
 Although it might have already been discussed.


We are aware of this: 
https://github.com/ldc-developers/ldc/issues/830

Regards,
Kai
May 30 2015
prev sibling parent "Kai Nacke" <kai redstar.de> writes:
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote:

 Not to mention that GDC and LDC benefit heavily from GCC and 
 LLVM respectively, these aren't exactly one man projects(e.g, 
 Google, Redhat, Intel, AMD etc contribute heavily to GCC and 
 LLVM is basically Apple's baby.)


Google, Intel, AMD, Imagination, ... also contribute to LLVM. I 
think most companies contributing to GCC contribute to LLVM, too.

Regards,
Kai
May 30 2015
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:

 On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via 
 Digitalmars-d wrote:

 In nearly every benchmark I see D in, the default compiler 
 used is dmd
 which runs computationally intense tasks 4-5x+ slower than 
 GDC/LDC


 As I keep saying, in my own compute-intensive projects I have
 consistently found that dmd-generated code (dmd -O -inline 
 -release) is
 about 20-30% slower on average, sometimes even up to 50% slower,
 compared to gdc-generated code (gdc -O3 -finline -frelease). 
 This is
 measured by actual running time in an actual application, not
 benchmark-specific code.

 I have looked at the generated assembly before, and it's clear 
 that the
 gdc optimizer is way ahead of dmd's. The dmd optimizer starts 
 failing to
 inline inner loop code after about 1-2 levels of function call 
 nesting,
 not to mention it's unable to factor out a lot of loop 
 boilerplate code.

 The gdc optimizer, by contrast, not only factors out almost all 
 loop
 boilerplate code and inlines inner loop function calls several 
 levels
 deep, it also unrolls loops in a CPU-specific way, does major 
 loop
 restructuring, compounded with much more linear code 
 optimization than
 dmd does, instruction reordering and then refactoring after 
 that, etc.,
 in some cases reducing the size of inner loop code (as in, the 
 amount of
 code that runs per iteration) by up to 90%.

 I don't know the internal workings of the dmd optimizer, but 
 it's clear
 that at present, with almost nobody working on it except 
 Walter, it's
 never going to catch up. (Maybe this statement will provoke 
 Walter into
 working his magic? :-P)


 [...]

 This isn't the first time I've seen this, in basically every 
 benchmark
 featuring D I have to submit a patch/make a comment that dmd 
 shouldn't
 be used. Make no mistake, this is damaging to D's reputation - 
 how
 well does D's "native efficiency" go over when people are 
 saying it's

 
 LDC and GDC need promoted more.


 [...]

 This will probably offend some people, but I think LDC/GDC 
 should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and 
 don't
 mind the speed compromise.


 T


LDC can work wonders, indeed. I've seen it. Drawback: GDC and LDC 
lag behind.

D doesn't like legacy code, so I always update my code.

Maybe we could synchronize dmd, ldc and gdc faster? Dmd is the 
only way to update your code.
May 29 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:

 [...]

This isn't the first time I've seen this, in basically every benchmark
featuring D I have to submit a patch/make a comment that dmd shouldn't
be used. Make no mistake, this is damaging to D's reputation - how
well does D's "native efficiency" go over when people are saying it's


LDC and GDC need promoted more.




 [...]

 This will probably offend some people, but I think LDC/GDC should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.


It should be more than just LDC/GDC being the default download on 
dlang.org, the DM backend and related toolchain should be phased out 
altogether in favor of LLVM.

Walter might have written great compiler tools in the 90s or so, but in 
today's internet and FOSS online-collaborative era, how can the Digital 
Mars toolchain hope to compete with toolchains having teams of multiple 
full-time developers working on it? (plus a plethora of occasional 
volunteer contributors). The difference in manpower and resources is 
astonishing! And it's only gonna get bigger since LLVM is having more 
and more people and companies supporting it. By this rate, it may well 
one day make even GCC old and obsolete, left to be used by FSF zealots only.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 05 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:

 [...]


This isn't the first time I've seen this, in basically every benchmark
featuring D I have to submit a patch/make a comment that dmd shouldn't
be used. Make no mistake, this is damaging to D's reputation - how
well does D's "native efficiency" go over when people are saying it's


LDC and GDC need promoted more.




 [...]


 This will probably offend some people, but I think LDC/GDC should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.



 It should be more than just LDC/GDC being the default download on


dlang.org, the DM backend and related toolchain should be phased out
altogether in favor of LLVM.

 Walter might have written great compiler tools in the 90s or so, but in


today's internet and FOSS online-collaborative era, how can the Digital
Mars toolchain hope to compete with toolchains having teams of multiple
full-time developers working on it? (plus a plethora of occasional
volunteer contributors). The difference in manpower and resources is
astonishing! And it's only gonna get bigger since LLVM is having more and
more people and companies supporting it. By this rate, it may well one day
make even GCC old and obsolete, left to be used by FSF zealots only.


At the risk of speaking with lack of foresight, are you on the gcc mailing
list too? If not, get on it. Otherwise you will enter this kind of
polarised view of X will dominate all.



 Jun 05 2015



 next sibling parent reply "weaselcat" <weaselcat gmail.com>  writes:


On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote:

 On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:

 On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:

 [...]


This isn't the first time I've seen this, in basically 
every benchmark
featuring D I have to submit a patch/make a comment that 
dmd shouldn't
be used. Make no mistake, this is damaging to D's 
reputation - how
well does D's "native efficiency" go over when people are 
saying it's


LDC and GDC need promoted more.




 [...]


 This will probably offend some people, but I think LDC/GDC 
 should be the
 default download on dlang.org, and dmd should be provided as 
 an
 alternative for those who want the latest language version 
 and don't
 mind the speed compromise.



 It should be more than just LDC/GDC being the default download 
 on


 dlang.org, the DM backend and related toolchain should be 
 phased out
 altogether in favor of LLVM.

 Walter might have written great compiler tools in the 90s or 
 so, but in


 today's internet and FOSS online-collaborative era, how can the 
 Digital
 Mars toolchain hope to compete with toolchains having teams of 
 multiple
 full-time developers working on it? (plus a plethora of 
 occasional
 volunteer contributors). The difference in manpower and 
 resources is
 astonishing! And it's only gonna get bigger since LLVM is 
 having more and
 more people and companies supporting it. By this rate, it may 
 well one day
 make even GCC old and obsolete, left to be used by FSF zealots 
 only.


 At the risk of speaking with lack of foresight, are you on the 
 gcc mailing
 list too? If not, get on it. Otherwise you will enter this kind 
 of
 polarised view of X will dominate all.


  Slightly off topic, but I recently started digging into GDC( on 
your personal fork, anyways.) I find the code pleasantly easy to 
navigate and understand. I don't think I've given gdc its due 
credit in this thead.

Bye,



 Jun 05 2015



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 6 June 2015 at 01:20, weaselcat via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote:


 On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:


 On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:


 [...]

  >This isn't the first time I've seen this, in basically >every

 benchmark

featuring D I have to submit a patch/make a comment that >dmd


 shouldn't

be used. Make no mistake, this is damaging to D's >reputation - how
well does D's "native efficiency" go over when people are >saying it's


LDC and GDC need promoted more.




 [...]


 This will probably offend some people, but I think LDC/GDC should be the
 default download on dlang.org, and dmd should be provided as an
 alternative for those who want the latest language version and don't
 mind the speed compromise.



 It should be more than just LDC/GDC being the default download on


 dlang.org, the DM backend and related toolchain should be phased out
 altogether in favor of LLVM.


 Walter might have written great compiler tools in the 90s or so, but in


 today's internet and FOSS online-collaborative era, how can the Digital
 Mars toolchain hope to compete with toolchains having teams of multiple
 full-time developers working on it? (plus a plethora of occasional
 volunteer contributors). The difference in manpower and resources is
 astonishing! And it's only gonna get bigger since LLVM is having more and
 more people and companies supporting it. By this rate, it may well one day
 make even GCC old and obsolete, left to be used by FSF zealots only.



 At the risk of speaking with lack of foresight, are you on the gcc mailing
 list too? If not, get on it. Otherwise you will enter this kind of
 polarised view of X will dominate all.


  Slightly off topic, but I recently started digging into GDC( on your
 personal fork, anyways.) I find the code pleasantly easy to navigate and
 understand. I don't think I've given gdc its due credit in this thead.

 Bye,


If you've been following the 2.067 re-work, that is really the way things
are going right now.  More encapsulation, less of the flat hierachal
structure is the key securing future interest.  My hope is that GDC will
fall into the "what a good frontend shoudl do" category after I'm done.



 Jun 05 2015



prev sibling  parent  Bruno Medeiros <bruno.do.medeiros+dng gmail.com>  writes:


On 05/06/2015 23:07, Iain Buclaw via Digitalmars-d wrote:

 On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d"
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:
  >
  > On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:
  >>
  >> [...]
  >>
  >>> >This isn't the first time I've seen this, in basically every benchmark
  >>> >featuring D I have to submit a patch/make a comment that dmd shouldn't
  >>> >be used. Make no mistake, this is damaging to D's reputation - how
  >>> >well does D's "native efficiency" go over when people are saying it's

  >>> >
  >>> >LDC and GDC need promoted more.
  >>
  >> [...]
  >>
  >>
  >> This will probably offend some people, but I think LDC/GDC should be the
  >> default download on dlang.org <http://dlang.org>, and dmd should be
 provided as an
  >> alternative for those who want the latest language version and don't
  >> mind the speed compromise.
  >
  >
  > It should be more than just LDC/GDC being the default download on
 dlang.org <http://dlang.org>, the DM backend and related toolchain
 should be phased out altogether in favor of LLVM.
  >
  > Walter might have written great compiler tools in the 90s or so, but
 in today's internet and FOSS online-collaborative era, how can the
 Digital Mars toolchain hope to compete with toolchains having teams of
 multiple full-time developers working on it? (plus a plethora of
 occasional volunteer contributors). The difference in manpower and
 resources is astonishing! And it's only gonna get bigger since LLVM is
 having more and more people and companies supporting it. By this rate,
 it may well one day make even GCC old and obsolete, left to be used by
 FSF zealots only.

 At the risk of speaking with lack of foresight, are you on the gcc
 mailing list too? If not, get on it. Otherwise you will enter this kind
 of polarised view of X will dominate all.


I'm not on any LLVM mailing list or forum either. It's too much volume 
for what I need to care/know about. I'm only on the LLVM Weekly 
newsletter. If GCC has a similar newsletter I might sign up to that.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros



 Jun 09 2015



prev sibling next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 29 May 2015 20:15, "weaselcat via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 In nearly every benchmark I see D in, the default compiler used is dmd


which runs computationally intense tasks 4-5x+ slower than GDC/LDC

 example of a random blog post I found:


http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html

 D is up to 10x(!) slower than Rust.

 Well... dmd is. Under LDC:
 MD5 is 5x faster,
 SHA1 is about the same,
 SHA256 is 10x faster,
 SHA512 is 10x faster.

 The kicker?
 _all_ of these were faster than the Rust timings(albeit by 5-10%) when


using LDC.

 This isn't the first time I've seen this, in basically every benchmark


featuring D I have to submit a patch/make a comment that dmd shouldn't be
used. Make no mistake, this is damaging to D's reputation - how well does
D's "native efficiency" go over when people are saying it's slower than


 LDC and GDC need promoted more.

 Bye,


It's also hurting in a lot of recent pull requests I've been seeing.
People are going out their way to micro optimise code for DMD, but
ultimately their intention ends up being rejected because of GDC/LDC
providing said optimisations for free.  It's not just PR, but also a
waste/drain on resource for people who could be better focusing their
limited free time.



 May 29 2015



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/29/15 12:13 PM, weaselcat wrote:

 In nearly every benchmark I see D in, the default compiler used is dmd
 which runs computationally intense tasks 4-5x+ slower than GDC/LDC

 example of a random blog post I found:
 http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html


One problem here is pointed by the blogger: "I tried to compile with 
LDC2 and failed (windows 7 x64): ..."

Can he be helped?


Andrei



 May 29 2015



  parent reply "Vladimir Panteleev" <thecybershadow gmail.com>  writes:


On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote:

 On 5/29/15 12:13 PM, weaselcat wrote:

 In nearly every benchmark I see D in, the default compiler
 used is dmd
 which runs computationally intense tasks 4-5x+ slower than
 GDC/LDC

 example of a random blog post I found: 
 http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html


 One problem here is pointed by the blogger: "I tried to compile 
 with LDC2 and failed (windows 7 x64): ..."

 Can he be helped?


http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471



 May 29 2015



  parent  "weaselcat" <weaselcat gmail.com>  writes:


On Friday, 29 May 2015 at 20:23:13 UTC, Vladimir Panteleev wrote:

 On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu 
 wrote:

 On 5/29/15 12:13 PM, weaselcat wrote:

 In nearly every benchmark I see D in, the default compiler
 used is dmd
 which runs computationally intense tasks 4-5x+ slower than
 GDC/LDC

 example of a random blog post I found: 
 http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html


 One problem here is pointed by the blogger: "I tried to 
 compile with LDC2 and failed (windows 7 x64): ..."

 Can he be helped?


 http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471


Thanks,

he updated the results.
DMD

     MD5 - 16.05s (470% slower)
     SHA1 - 2.35s (19% faster)
     SHA256 - 47.96s (690% slower (!))
     SHA512 - 61.47s (1375% slower (!))

LDC2

     MD5 - 2,18s (55% faster)
     SHA1 - 2.88s (same)
     SHA256 - 6,79s (3% faster)
     SHA512 - 4,6s (3% slower)

% is compared to Rust.



 May 29 2015



prev sibling next sibling parent reply "Martin Krejcirik" <mk-junk i-line.cz>  writes:


IMHO all what is needed is to update the download page with some 
description of deferences between the compilers, like:

dmd
   - reference compiler, Digital Mars backend
   - best for latest dlang features, fast compile times

gdc
   - GNU gcc backend based compiler
   - best for portability and compatibility with gnu tools

ldc
   - LLVM backend based compiler
   - best for optimized builds, best runtime speed

Note to benchmark users: please use ldc compiler with -inline -O 
-boundscheck=off (or whatever is correct for LDC) options for 
best results



 May 29 2015



 next sibling parent  "Dennis Ritchie" <dennis.ritchie mail.ru>  writes:


On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:

 IMHO all what is needed is to update the download page with 
 some description of deferences between the compilers, like:


+1



 May 29 2015



prev sibling next sibling parent  "weaselcat" <weaselcat gmail.com>  writes:


On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:

 Note to benchmark users: please use ldc compiler with -inline 
 -O -boundscheck=off (or whatever is correct for LDC) options 
 for best results


AFAIK you shouldn't use the -inline flag with LDC, as it tells 
LDC to run the inline LLVM pass. LDC's inlining is enabled with 
-enable-inlining and is enabled at -O2 and higher. I believe 
these are similar except LDC's -enable-inlining has better cost 
analysis configured for the pass(?)

-inline should probably be renamed because this is confusing due 
to dmd's usage of it.

But yes, a simple blurb on which compiler flags to use for 
optimization would probably help as there seems to be some 
confusion about this due to differing compiler flags. I imagine 
Iain, Kai, Nadlinger, etc would know which ones to use.



 May 29 2015



prev sibling  parent reply ketmar <ketmar ketmar.no-ip.org>  writes:


On Fri, 29 May 2015 20:02:47 +0000, Martin Krejcirik wrote:


 dmd
    - reference compiler, Digital Mars backend - best for latest dlang
    features, fast compile times
=20
 gdc
    - GNU gcc backend based compiler - best for portability and
    compatibility with gnu tools
=20
 ldc
    - LLVM backend based compiler - best for optimized builds, best
    runtime speed


does LDC really surpasses GDC in generated code speed?=



 May 29 2015



  parent reply "weaselcat" <weaselcat gmail.com>  writes:


On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote:

 On Fri, 29 May 2015 20:02:47 +0000, Martin Krejcirik wrote:


 dmd
    - reference compiler, Digital Mars backend - best for 
 latest dlang
    features, fast compile times
 
 gdc
    - GNU gcc backend based compiler - best for portability and
    compatibility with gnu tools
 
 ldc
    - LLVM backend based compiler - best for optimized builds, 
 best
    runtime speed


 does LDC really surpasses GDC in generated code speed?


yes
GDC is 2-3x slower than LDC on this bench for example.
I think it's because of a lack of cross module inlining.



 May 29 2015



  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Fri, 29 May 2015 23:29:39 +0000, weaselcat wrote:


 On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote:

 On Fri, 29 May 2015 20:02:47 +0000, Martin Krejcirik wrote:


 dmd
    - reference compiler, Digital Mars backend - best for
 latest dlang
    features, fast compile times
=20
 gdc
    - GNU gcc backend based compiler - best for portability and
    compatibility with gnu tools
=20
 ldc
    - LLVM backend based compiler - best for optimized builds,
 best
    runtime speed


 does LDC really surpasses GDC in generated code speed?


=20
 yes GDC is 2-3x slower than LDC on this bench for example. I think it's
 because of a lack of cross module inlining.


thanks for the info.=



 May 29 2015



prev sibling  parent reply "Kyoji Klyden" <kyojiklyden yahoo.com>  writes:


Honestly I've never taken DMD to be "the production compiler". 
I've always left that to the GNU compilers. GDC has all the magic 
and years of work with it's backend, so I'm not sure how dmd can 
compare. As others of said, it's really the frontend that DMD is 
providing that matters; once you have that you can more or less 
just stick that onto which ever backend works for you. Though DMD 
is definitely not entirely useless, I use it all the time, mainly 
for prototypes, quick builds, and testing libraries.

Also if someone is to do speed tests to see how powerful D is, 
how clueless would they have to be to check only dmd? You don't 
just compile C++ with MSVC, and then say "Welp, it looks like C++ 
is just slow and shitty". :P
You can probably safely dismiss any speed test that shows you 
only one compiler.


So personally I vote that speed optimizations on DMD are a waste 
of time at the moment.



 May 30 2015



  parent reply ketmar <ketmar ketmar.no-ip.org>  writes:


On Sat, 30 May 2015 12:00:57 +0000, Kyoji Klyden wrote:


 So personally I vote that speed optimizations on DMD are a waste of time
 at the moment.


it's not only waste of time, it's unrealistic to make DMD backend's=20
quality comparable to GDC/LDC. it will require complete rewrite of backend=20
and many man-years of work. and GDC/LDC will not simply sit frozen all=20
this time.=



 May 30 2015



  parent reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com>  writes:


On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote:

 On Sat, 30 May 2015 12:00:57 +0000, Kyoji Klyden wrote:


 So personally I vote that speed optimizations on DMD are a 
 waste of time
 at the moment.


 it's not only waste of time, it's unrealistic to make DMD 
 backend's
 quality comparable to GDC/LDC. it will require complete rewrite 
 of backend
 and many man-years of work. and GDC/LDC will not simply sit 
 frozen all
 this time.


+1 for LDC as first class!

D would become a lot more appealing if it could take advantage of 
the LLVM tooling already available!

Regarding the speed problem - One could always have LDC have a 
nitro switch, where it simply runs less of the expensive passes, 
thus reducing the codegen quality, but improving speed. Would 
that work? I'm assuming the "slowness" in LLVM comes from the 
optimization passes.

Would clang's thread-sanitizer and address-sanitizer be adaptable 
and usable with D as well?



 May 30 2015



 next sibling parent  "weaselcat" <weaselcat gmail.com>  writes:


On Saturday, 30 May 2015 at 17:00:18 UTC, Márcio Martins wrote:

 Would clang's thread-sanitizer and address-sanitizer be 
 adaptable and usable with D as well?


these are already usable from LDC.
make sure you use the -gcc=clang flag.



 May 30 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 30 May 2015 19:05, "via Digitalmars-d" <digitalmars-d puremagic.com>
wrote:

 On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote:

 On Sat, 30 May 2015 12:00:57 +0000, Kyoji Klyden wrote:


 So personally I vote that speed optimizations on DMD are a waste of time
 at the moment.



 it's not only waste of time, it's unrealistic to make DMD backend's
 quality comparable to GDC/LDC. it will require complete rewrite of




backend

 and many man-years of work. and GDC/LDC will not simply sit frozen all
 this time.



 +1 for LDC as first class!

 D would become a lot more appealing if it could take advantage of the


LLVM tooling already available!

 Regarding the speed problem - One could always have LDC have a nitro


switch, where it simply runs less of the expensive passes, thus reducing
the codegen quality, but improving speed. Would that work? I'm assuming the
"slowness" in LLVM comes from the optimization passes.


I'd imagine the situation is similar with GDC.  For large compilations,
it's the optimizer, for small compilations, it's the linker.  Small
compilations is at least solved by switching to shared libraries.  For
larger compilations, only using -O1 optimisations should be fine for most
programs that aren't trying to beat some sort of benchmark.



 May 30 2015