Getting ready for 2.061

[Russel Winder]

On Sat, 2012-12-22 at 17:41 +0100, David Nadlinger wrote:
[…]
> If you ever have time to do some quick profiling, could you 
> please try to figure out why the LDC-generated executable is 
> slower – or if the code you are working on is open source, put 
> some instructions together on how to run the benchmark(s)? The 
> LLVM backend really shouldn't produce slower code than DMD in 
> just about any situation, so most likely we are doing something 
> stupid in LDC.

Can you point me at tools and documentation for profiling that generates
the data that would be useful to you. I am very much an LLVM n00b.  I
just compile and use LDC and compile and install LLVMPy, so all of LLVM
is under the covers for me.

The codes are all published on GitHub
https://github.com/russel/Pi_Quadrature this is an embarrasingly
parallel summation problem, approximating  π by quadrature. This is the
example David used for one of the std.parallelism examples. The codes
use SCons for compile and execution. So to compile and run pi_d_spawn.d:

	scons run_pi_d_spawn

Though you will want to use my "D tools fork" of SCons which is a
Mercurial repository at BitBucket
https://bitbucket.org/russel/scons_d_tooling No need to install SCons
can be executed from the clone by:

	python /path/to/scons-clone/bootstrap.py run_pi_d_spawn

> I'm really interested in this, because apart from target platform 
> support (druntime/ARM is still not there yet, though) and some 
> very few DMD-specific bugs such as the one you seem to hit, there 
> is little reason to use LDC other than for the its code 
> generation.

The pattern of when DMD beats LDC on my machines is weird.  However,
this is all currently just anecdotal evidence, I have not done a proper
experiment that can give any statistical significance to the claims
made.

LDC generally beats DMD by about 2%–4%, but in some cases by
extraordinary amounts, but I think this shows failures in DMD rather
than success of LDC since the LDC time is about what it should be.

The case where I thought DMD was beating LDC may be a misobservation
(i.e. statistics needed) and that it is just that DMD is performing
unusually as well as LDC. This is the pi_d_spawn.d code.

pi_d_threadsGlobalState_array_declarative causes both DMD and LDC to
barf, with the same problem I think.

pi_d_threadsGlobalState_array_iterative.d LDC works and DMD barfs.

pi_d_threadsGlobalState_threadGroup.d DMD behaves weirdly, LDC gets
things right.

This first one of this trio is the 2.059 → 2.060 regression reported if
I remember correctly. Ithought I had reported this last one as well
since I am fairly sure 2.059 did not behave as 2.060 does.

> Oh, and if you get around to doing this before the next LDC 
> release, could you please try it on a Git master build, and if 
> you are on a 32 bit system, ideally use LLVM 3.2+? We had to 
> disable optimizations on earlier LLVM versions for x86 builds of 
> druntime due to a LLVM codegen bug only fixed in 3.2, and the 
> GC-to-stack-promotion pass now activated in master should catch a 
> few cases where we do stupid things like allocating array 
> manifest constants on every entry into function, even if they 
> were only used for meta-programming.

I only ever use Git master, at least until Debian package a useful
version of LDC, then I'll have to make a decision.

I am usually 64-bit Linux, I can also do 64-bit OS X. Windows exists
only in a plane of the multiverse that I never frequent. :-)

> There is still a single known issue which can drastically affect 
> GC performance, though: 
> https://github.com/ldc-developers/ldc/issues/233. There is an 
> easy fix, but it completely breaks shared libraries (but given 
> that those don't work reliably anyway, I think I'll just go with 
> it for the time being…)

:-)



-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20121222/d230f9f1/attachment.pgp>