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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part