Jarrett Billingsley wrote:
> I hope bearophile will eventually understand that DMD is not good at
> optimizing code, and so comparing its output to GCC's is ultimately
> meaningless.

The long arithmetic benchmark is completely (and I mean completely) dominated by the time spent in the long divide helper function. The timing results for it really have nothing to do with the compiler optimizer or code generator. Reducing the number of instructions in the loop by one or improving pairing slightly does nothing when stacked up against maybe 50 instructions in the long divide helper function.

The long divide helper dmd uses (phobos\internal\llmath.d) is code I basically wrote 25 years ago and have hardly looked at since except to carry it forward. It uses the classic shift-and-subtract algorithm, but there are better ways to do it now with the x86 instruction set.

Time to have some fun doing hand-coded assembler again!

Fixing this should bring that loop timing up to par, but it's still not a good benchmark for a code generator. Coming up with good *code generator* benchmarks is hard, and really can't be done without looking at the assembler output to make sure that what you think is happening is what is actually happening.

I've seen a lot of benchmarks over the years, and too many of them do things like measure malloc() or printf() speed instead of loop optimizations or other intended measurements. Caching and alignment issues can also dominate the results.

I haven't looked closely at the other loop yet.

On Sun, Dec 14, 2008 at 3:22 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> Walter is the only one who can make DMD faster, and I think his time is much better spent on designing and maintaining the language.  The reference compiler is just supposed to be _correct_, not necessarily _fast_.  If Walter spent all his time working on making the the DMDFE optimizer better and making DMD backend produce faster code, he wouldn't have time to work on the language anymore, and it would be duplicated effort since GDC and LDC already do it better.
>
> But there are other reasons to keep the back end. Sometimes, I need to tweak it to support something specific. For example,
>
> 1. the stuff to hook together module constructors
> 2. thread local storage
> 3. position independent code
> 4. support for various function call sequences
> 5. D symbolic debug info
> 6. Generating libraries directly
> 7. Breaking a module up into multiple object files
>
> and coming soon:
>
> 8. insertion of memory fences
> Other possibilities are D specific optimizations, like taking advantage of
> immutability and purity, that I doubt exist in a back end designed for
> C/C++.

Of course that back end was also designed for C/C++ originally, right? But anyway, I agree with bearophile, that requiring too many special features out of a back end will make it hard for any alternative D compilers to keep up.

> While of course all this can be added to any back end, I understand how to do it to mine, and it would take me a lot of time to understand another well enough to be able to know just where to put the fix in.

That's understandable, but at some point it becomes worth the effort to learn something new.  Many people get by just fine using C++.  They may be interested in D, but it just takes too much effort.  However, a little effort invested in learning D pays off (at least we all believe so or we wouldn't be here).  Likewise, if there were a really solid well-maintained back end with a liberal open source license that generates great code, it would very likely be worth your time to learn it, even though it might be rough going in the short term.

> Another thing I'd be very unwilling to give up on with the dmd back end is how fast it is. DMC is *still* by far the fastest compiler out there.

I'd gladly trade fast compilation for "has a future" or "supports 64-bit architectures" or "generates faster code" or "doesn't crash when there are too many fixups in main()".   Have you seen the messages about how long it can take to compile DWT applications?  DWT progs are already desperately in need of some smarter dependency tracking and ability to do minimal recompilations.  I think implementing that (in a build system or whatever) would more than make up for the loss in raw compilation speed.  Besides, I think a chunk of the the compilation speed is thanks to the module system, and avoiding the endless reparsing required for C++ #includes.  So any D compiler should benefit.

Anyone have the data for the time required to compile tango with DMD vs LDC?  It would be interesting to see how bad the difference is.

Anyway, all that said,  it's not clear that we really do have that mythical "uber backend" available right now.

According to my conversations on the clang mailing list, the current
target is for LLVM to be able to fully support a C++ compiler by 2010.
 I'm not quite sure what all that involves, but apparently it includes
things like making exceptions work on Windows.  So it certainly does
look a bit premature to move over to LLVM as the primary platform for
D at this point.

--bb

Bill Baxter wrote:
> Of course that back end was also designed for C/C++ originally, right?

Pretty much all of them are.

> But anyway, I agree with bearophile, that requiring too many special
> features out of a back end will make it hard for any alternative D
> compilers to keep up.

I'm aware of that, but I'm also aware of the crippling workarounds cfront had to use to avoid changing *anything* in the back end, because cfront had no control over them. There are still some suboptimal things in C++ due to trying to avoid changing the rest of the tool chain.


>> While of course all this can be added to any back end, I understand how to
>> do it to mine, and it would take me a lot of time to understand another well
>> enough to be able to know just where to put the fix in.
> 
> That's understandable, but at some point it becomes worth the effort
> to learn something new.  Many people get by just fine using C++.  They
> may be interested in D, but it just takes too much effort.  However, a
> little effort invested in learning D pays off (at least we all believe
> so or we wouldn't be here).  Likewise, if there were a really solid
> well-maintained back end with a liberal open source license that
> generates great code, it would very likely be worth your time to learn
> it, even though it might be rough going in the short term.

Such doesn't exist, however. I remember efforts back in the early 80's to build one (the PCC, for example).

>> Another thing I'd be very unwilling to give up on with the dmd back end is
>> how fast it is. DMC is *still* by far the fastest compiler out there.
> 
> I'd gladly trade fast compilation for "has a future" or "supports
> 64-bit architectures" or "generates faster code" or "doesn't crash
> when there are too many fixups in main()".   Have you seen the
> messages about how long it can take to compile DWT applications?  DWT
> progs are already desperately in need of some smarter dependency
> tracking and ability to do minimal recompilations.  I think
> implementing that (in a build system or whatever) would more than make
> up for the loss in raw compilation speed.  Besides, I think a chunk of
> the the compilation speed is thanks to the module system, and avoiding
> the endless reparsing required for C++ #includes.  So any D compiler
> should benefit.

DMC is the fastest C/C++ compiler. DMD benefits from much of the work that went in to make it fast. I did design the semantics of D to favor fast parsing speeds, but there's still the back end speed which has nothing to do with parsing semantics.

I found out yesterday that gcc still generates *text* assembler files which are then fed to the assembler for all compiles. That just cannot be made to be speed competitive.

> Anyone have the data for the time required to compile tango with DMD
> vs LDC?  It would be interesting to see how bad the difference is.
> 
> Anyway, all that said,  it's not clear that we really do have that
> mythical "uber backend" available right now.
> 
> According to my conversations on the clang mailing list, the current
> target is for LLVM to be able to fully support a C++ compiler by 2010.
>  I'm not quite sure what all that involves, but apparently it includes
> things like making exceptions work on Windows.  So it certainly does
> look a bit premature to move over to LLVM as the primary platform for
> D at this point.

Abandoning dmd's back end now then would entail a 2 year delay with no updates, and I guarantee that there'll be years of wringing bugs out of LLVM. Writing a cg for a complex instruction set like the x86 is, well, pretty complicated <g> with thousands of special cases.

One thing that made D possible was I was able to use a mature, professional quality, debugged optimizer and back end. The lack of that has killed many otherwise promising languages in the past.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Abandoning dmd's back end now then would entail a 2 year delay with no
> updates, and I guarantee that there'll be years of wringing bugs out of
> LLVM. Writing a cg for a complex instruction set like the x86 is, well,
> pretty complicated <g> with thousands of special cases.
> One thing that made D possible was I was able to use a mature,
> professional quality, debugged optimizer and back end. The lack of that
> has killed many otherwise promising languages in the past.

I do agree to a large extent with the argument that Walter's time is better spent on the language itself rather than on messing with compiler back ends, but just to play devil's advocate:  What happens when x86-32 is irrelevant because everyone's using 64-bit?  Could DMD eventually be made to support x86-64 codegen w/o too much work, given that it already supports x86-32?  How much longer do others on this newsgroup think x86-32 will be the dominant compiler target?

On Mon, Dec 15, 2008 at 11:37 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Of course that back end was also designed for C/C++ originally, right?
>
> Pretty much all of them are.
>
>> But anyway, I agree with bearophile, that requiring too many special features out of a back end will make it hard for any alternative D compilers to keep up.
>
> I'm aware of that, but I'm also aware of the crippling workarounds cfront had to use to avoid changing *anything* in the back end, because cfront had no control over them. There are still some suboptimal things in C++ due to trying to avoid changing the rest of the tool chain.
>
>
>>> While of course all this can be added to any back end, I understand how
>>> to
>>> do it to mine, and it would take me a lot of time to understand another
>>> well
>>> enough to be able to know just where to put the fix in.
>>
>> That's understandable, but at some point it becomes worth the effort to learn something new.  Many people get by just fine using C++.  They may be interested in D, but it just takes too much effort.  However, a little effort invested in learning D pays off (at least we all believe so or we wouldn't be here).  Likewise, if there were a really solid well-maintained back end with a liberal open source license that generates great code, it would very likely be worth your time to learn it, even though it might be rough going in the short term.
>
> Such doesn't exist, however. I remember efforts back in the early 80's to build one (the PCC, for example).
>
>>> Another thing I'd be very unwilling to give up on with the dmd back end
>>> is
>>> how fast it is. DMC is *still* by far the fastest compiler out there.
>>
>> I'd gladly trade fast compilation for "has a future" or "supports 64-bit architectures" or "generates faster code" or "doesn't crash when there are too many fixups in main()".   Have you seen the messages about how long it can take to compile DWT applications?  DWT progs are already desperately in need of some smarter dependency tracking and ability to do minimal recompilations.  I think implementing that (in a build system or whatever) would more than make up for the loss in raw compilation speed.  Besides, I think a chunk of the the compilation speed is thanks to the module system, and avoiding the endless reparsing required for C++ #includes.  So any D compiler should benefit.
>
> DMC is the fastest C/C++ compiler. DMD benefits from much of the work that went in to make it fast. I did design the semantics of D to favor fast parsing speeds, but there's still the back end speed which has nothing to do with parsing semantics.
>
> I found out yesterday that gcc still generates *text* assembler files which are then fed to the assembler for all compiles. That just cannot be made to be speed competitive.
>
>> Anyone have the data for the time required to compile tango with DMD vs LDC?  It would be interesting to see how bad the difference is.
>>
>> Anyway, all that said,  it's not clear that we really do have that mythical "uber backend" available right now.
>>
>> According to my conversations on the clang mailing list, the current
>> target is for LLVM to be able to fully support a C++ compiler by 2010.
>>  I'm not quite sure what all that involves, but apparently it includes
>> things like making exceptions work on Windows.  So it certainly does
>> look a bit premature to move over to LLVM as the primary platform for
>> D at this point.
>
> Abandoning dmd's back end now then would entail a 2 year delay with no updates, and I guarantee that there'll be years of wringing bugs out of LLVM. Writing a cg for a complex instruction set like the x86 is, well, pretty complicated <g> with thousands of special cases.

Right.  I was agreeing with you there (or you are agreeing with me there).  From the 2010 figure the clang guys gave me it indeed sounds like LLVM will not be viable as D's *primary* backend for at least two years.

I'm perfectly happy to accept reasonable arguments that the current
alternatives are not good enough yet (LLVM) or have unacceptable
licensing terms (GCC).
But arguing that it would take too much time to learn something new is
not convincing to me.  Nor is an argument that the backend needs
special feature X.  If the back end is really open source, then
maintainers should not object to the addition of features needed by a
hosted language -- as long as those features do not interfere with
other hosted languages, and I see no reason why they should.

--bb

> Anyone have the data for the time required to compile tango with DMD vs LDC?  It would be interesting to see how bad the difference is.

Compiling tango-user-{ldc,dmd}
DMD - 20.950s
LDC - 34.891s

On Mon, Dec 15, 2008 at 12:37 PM, naryl <cyNOSPAM@ngs.ru> wrote:
>> Anyone have the data for the time required to compile tango with DMD vs LDC?  It would be interesting to see how bad the difference is.
>
> Compiling tango-user-{ldc,dmd}
> DMD - 20.950s
> LDC - 34.891s

Thanks for the data.  Seems not so bad to me.
Could be better, but could be a lot worse.

--bb

I have already hit long division related speed issues in my D code. Sometimes simple things can dominate a benchmark, but those same simple things can dominate user code too!

Walter Bright Wrote:

> Jarrett Billingsley wrote:
> > I hope bearophile will eventually understand that DMD is not good at optimizing code, and so comparing its output to GCC's is ultimately meaningless.
> 
> The long arithmetic benchmark is completely (and I mean completely) dominated by the time spent in the long divide helper function. The timing results for it really have nothing to do with the compiler optimizer or code generator. Reducing the number of instructions in the loop by one or improving pairing slightly does nothing when stacked up against maybe 50 instructions in the long divide helper function.
> 
> The long divide helper dmd uses (phobos\internal\llmath.d) is code I basically wrote 25 years ago and have hardly looked at since except to carry it forward. It uses the classic shift-and-subtract algorithm, but there are better ways to do it now with the x86 instruction set.
> 
> Time to have some fun doing hand-coded assembler again!
> 
> Fixing this should bring that loop timing up to par, but it's still not a good benchmark for a code generator. Coming up with good *code generator* benchmarks is hard, and really can't be done without looking at the assembler output to make sure that what you think is happening is what is actually happening.
> 
> I've seen a lot of benchmarks over the years, and too many of them do things like measure malloc() or printf() speed instead of loop optimizations or other intended measurements. Caching and alignment issues can also dominate the results.
> 
> I haven't looked closely at the other loop yet.

Jason House wrote:
> I have already hit long division related speed issues in my D code.
> Sometimes simple things can dominate a benchmark, but those same
> simple things can dominate user code too!

I completely agree, and I'm in the process of fixing the long division. My point was it has nothing to do with the code generator, and that drawing conclusions from a benchmark result can be tricky.

Bill Baxter wrote:
> I'm perfectly happy to accept reasonable arguments that the current
> alternatives are not good enough yet (LLVM) or have unacceptable
> licensing terms (GCC).
> But arguing that it would take too much time to learn something new is
> not convincing to me.  Nor is an argument that the backend needs
> special feature X.  If the back end is really open source, then
> maintainers should not object to the addition of features needed by a
> hosted language -- as long as those features do not interfere with
> other hosted languages, and I see no reason why they should.

Controlling the back end also enables dmd to do some fun things like generate libraries directly - not only does this dramatically speed up library builds, it increases the granularity by building multiple object files per module.

I'd like to have it do a link, too, so dmd could directly generate executables!