[dmd-internals] building dmd with the microsoft compiler
Rainer Schuetze
r.sagitario at gmx.de
Sun Nov 13 08:13:46 PST 2011
Hi,
a few days ago, I was trying to figure out why dmd takes so long
compiling my projects. (The usual development build time for
VisualD+parser is about 40 seconds which starts to get annoying. With
enabled GC it was more than a minute. Comparing this with the C++
project at work which is about 50 times larger, but only takes about 10
seconds to (incrementally) build with changes to a few files, I think
there is something wrong with the D compilation model. But this is a
different topic.)
Activating the profiler didn't help (crashes or takes forever), so I
pushed the dmd source through the Microsoft compiler (I'm currently
using cl v15 that comes with VS2008). Using the Microsoft compiler has
several advantages
- way better debug information and integration into current debuggers
- better support for instrumented/sampling profiling tools
- better dependency handling for building dmd (if used from within
Visual Studio)
- the executable can use up to 4GB memory on Win 64-bit host, up to 3GB
memory on Win32
The downsides are
- no 80-bit float support
- no C99 sprintf (%j, %z, %a)
- restricted structured exception handling
I have patched the compiler to use handcrafted implementations and it
now passes the dmd test suite.
Quite a bit to my surprise, the compiler is also almost twice as fast on
my projects as the dmc compiled dmd! The test suite runs a bit slower
though (5% to 10%).
Is there interest in adding the patches to the dmd source? I would like
to do some cleanup before creating a pull request.
The major changes are with respect to the 80-bit floats, because this
also leaks into the backend. Mostly, it's replacing "long double" with
my implementation "long_double". I've seen "d-gcc-real.h" being used if
IN_GCC is defined, but the defined type real_t is only referred to
partially. I wonder whether this is still in use (by LDC/GDC?) and
whether it ever passed the test suites?
The C99 printf functions are overloaded by inserting an include file on
the command line, I would prefer if these would go into port.c/h, but
these would need to be included by the backend aswell then.
I have also built a 64-bit executable of dmd building 32-bit code, but
it does not perform aswell (somewhere between dmc and msc 32-bit versions).
Rainer
More information about the dmd-internals
mailing list