www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D 2.061 release

reply Russel Winder <russel winder.org.uk> writes:
I just thought I should report that 2.061 has fixed all the threading
problems I was moaning about after the 2.059 =E2=86=92 2.060 update.  So th=
anks
to all concerned with fixing the bug reports that were generated.

LDC is though still generally creating faster executables than DMD. This
is just a gut feeling right now, in a couple of weeks time I'll see if I
can get some actual numbers.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2013 3:13 AM, Russel Winder wrote:

 I just thought I should report that 2.061 has fixed all the threading
 problems I was moaning about after the 2.059 → 2.060 update.  So thanks
 to all concerned with fixing the bug reports that were generated.


That is great news!



 LDC is though still generally creating faster executables than DMD. This
 is just a gut feeling right now, in a couple of weeks time I'll see if I
 can get some actual numbers.


It's also helpful to drill down to see why. For example, a while back a D user 
posted a benchmark where he concluded that dmd generated poor code for integer 
math. Drilling down into the generated code, it was pretty much the same as
what 
other compilers generated. What was different, however, was the implementation 
of the "long divide" library function. druntime had a slow one. The long divide 
dominated the performance profile. Fixing that brought it up to par with zero 
changes to the compiler.

I've also seen benchmarks where the compiler was blamed, where malloc, or 
printf, or strcpy, or whatever was the actual dominant cycle sucker. Or even 
that the wrong compiler switches were used. Yes, I've seen magazines publish 
benchmarks where the 'slow' compiler was used with debug switches on, and the 
'fast' compiler had the optimization switches on.
Jan 07 2013
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 7 January 2013 at 20:23:37 UTC, Walter Bright wrote:

 I've also seen benchmarks where the compiler was blamed, where 
 malloc, or printf, or strcpy, or whatever was the actual 
 dominant cycle sucker. Or even that the wrong compiler switches 
 were used. Yes, I've seen magazines publish benchmarks where 
 the 'slow' compiler was used with debug switches on, and the 
 'fast' compiler had the optimization switches on.


  Sounds rigged. I know I've heard of benchmarks from years ago 
where a windows server system (2000?) was against a linux server; 
The windows machine had like a gig of memory and a bunch of other 
snazzy hardware, while the linux machine was giving the bare 
minimum to run the server (32-128Mb). Also I think Microsoft was 
the one doing the benchmarks... :)
Jan 07 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2013 1:08 PM, Era Scarecrow wrote:

   Sounds rigged. I know I've heard of benchmarks from years ago where a windows
 server system (2000?) was against a linux server; The windows machine had like
a
 gig of memory and a bunch of other snazzy hardware, while the linux machine was
 giving the bare minimum to run the server (32-128Mb). Also I think Microsoft
was
 the one doing the benchmarks... :)


Most of the time it was just incompetence.

On one, the benchmark table results showed Zortech was the fastest, but the 
article text asserted that Major Brand X was the fastest.
Jan 07 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 It's also helpful to drill down to see why.


I agree. Performance of the resulting code doesn't come out of 
magic, it comes from one or more (usually many) small stupid 
steps done by some optimization module, etc etc. If you locate 
the problem exactly, it's often possible to improve the 
"compiler". See below.



 For example, a while back a D user posted a benchmark where he 
 concluded that dmd generated poor code for integer math.


That person concluded that DMD was doing a worse job in compiling 
that code.

 From similar discussions it seems that the problem is that what 
you call "compiler" isn't what most people think of "compiler". 
For me the "long divide" is part of what the compiler does.

Bye,
bearophile
Jan 07 2013