[dmd-internals] Windows DMD development is now impossible

Andrei Alexandrescu andrei at erdani.com
Mon Jun 10 11:42:41 PDT 2013


Very interesting stuff. Couple of thoughts:

1. Does the windows unittest build an executable with all unittests, as 
it used to? Then it should probably switch to the Posix approach (one 
executable per tested module).

2. It seems a clean cut of templates is emerging:

(a) For strictly type-related stuff, prefer templates.

(b) For all other compile-time work, prefer CTFE.

It used to be a matter of preference, but I think practical reasons 
suggest that straight CTFE should be the natural and recommended 
approach to doing a variety of things during compilation.

3. It seems a new tactical approach to writing libraries is emerging: in 
template-heavy libraries, most or all top-level imports should be pushed 
down into the templates using them. That way the cost of importing e.g. 
levenshteinDistance() if all you need is copy() is just the cost of 
parsing (small). Only with actual use of templates will the necessary 
modules be imported. I will discuss it along with a related enhancement 
request in a DIP.


Andrei

On 6/10/13 5:25 AM, Martin Nowak wrote:
> On 06/10/2013 08:29 AM, Don Clugston wrote:
>> Yeah, my point was that for N tests, we get O(N^^2) templates
>> instantiated.
> How is that?
>
>  > Wow! (How many of those are unique, rather than reusing an existing
> instantiation?)
>
> The number of instances is also a huge performance issue when searching
> for existing instantiations, because search is done linear and comparing
> two TemplateInstance uses the costly arrayObjectMatch on the template
> arguments. So in average instantiating the same template N times uses
> O(N^^2 / 2) comparisons.
> I once improved that by computing the mangling before the search and
> using it as a key.
> That brought down the compilation time of std.range with unittests from
> 10 to 2 seconds.
> There is at least one blocker though
> http://d.puremagic.com/issues/show_bug.cgi?id=7469.
>
>  > Error: out of memory
>  > This has happened many times before, and we dealt with it by reducing
> the number of modules we compiled into each object file. We once had 30
> modules per obj file. Then fifteen. Then five. But now we're at one,
> that workaround can no longer be used.
>
> I ran into some issue when preparing the phobos unittests for shared
> libraries.
> If you compile the whole library at once with unittests enabled it
> consumes ~6GB of RAM.
> In order to find a good partition I took up the idea of clustering (
> http://d.puremagic.com/issues/show_bug.cgi?id=9673#c2,
> https://gist.github.com/dawgfoto/5747405). Well, at least clustering by
> imports did only find a few useful partitions because almost every
> module ends up importing std.range or std.algorithm. It might be
> interesting to do some analysis for the template instances used in each
> module.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals


More information about the dmd-internals mailing list