D compiles fast, right? Right??

[H. S. Teoh]

On Tue, Apr 03, 2018 at 11:09:10PM +0000, burjui via Digitalmars-d wrote:
[...]
> H. S. Teoh is not the only one here cringing at "fast code fast" on
> the main page. I use D from time to time for over 10 years now, and
> even used it at work and it was a relatively positive experience,
> thanks to vibe.d. But compilation times are just horrible - minimum 3
> seconds for a 1500 lines project (on a 8-core 4GHz CPU with 16 GB
> RAM), and that's after I ditched std.regex, made all imports qualified
> (didn't help that much, though) and switched to ld.gold.

3 seconds for 1500 lines?  Is that because you're using dub with its
unbearably slow compulsive network lookups?  Or because you imported
monsters like std.format?  Or because you have heavily-templated code?
Vibe.d is pretty heavy on templates (Diet templates, while pretty cool
from a geekiness POV, also slow things down like a hog because of heavy
template + CTFE usage).

Also, which compiler version did you use?  If you use nested templates
heavily (like UFCS chains of ranges), in older releases you may have run
into the exponential symbol size problem, where most of the compilation
time is spent generating, looking up, and reading symbols that are tens
of megabytes long.  After Rainers' symbol compression PR was merged,
compilation times on such code was hugely improved. As of a release or
two ago, this is no longer a problem.

I've noticed that if I don't use certain slow things, dmd is actually
lightning fast at compiling up to several thousand LOCs.  But as soon as
std.format enters the picture, or if you have recursive templates or
heavy CTFE, it rapidly deteriorates.  (Note, though, that relatively
simple template code doesn't significantly slow things down; it's when
you start doing things like manipulating type tuples AKA AliasSeq's,
recursive templates, compile-time loops like static foreach over
introspection, heavy CTFE, that things start grinding. Simple
parametrized types are still lightning fast, and last time I checked a
lot faster than, say, equivalent C++ code compiled with g++.)


> And I would be ok with slow compilation if DMD was smart enough, doing
> some graph magic, like extensive control flow analysis, and insane
> optimizations, but it doesn't. For example, Rust compilation times are
> no picnic either, but it's obvious why - you get nice good-looking
> error messages, tons of useful warnings and very fast programs free of
> memory corruption bugs. It's not the case with DMD, though. The
> language may be better than C++, but it's fastest compiler is slower
> and produces worse code? I'd rather not boast about speed at the main
> page in this situation.  And god save us from ridicule by Goers.

These days, I don't even look at benchmarks of dmd-compiled code
anymore.  For anything even remotely performance-related, I look at
gdc/ldc.  They do compile noticeably slower than dmd, but with the huge
benefit of far superior backends that gives me top runtime performance.

If Andrei & Walter are serious about this "fast code fast" thing, then
we'd better get our act together and do some serious optimization work,
both on the compiler itself, and on the quality of its codegen.


T

-- 
Bomb technician: If I'm running, try to keep up.