On Sat, 07 Jul 2012 17:04:35 -0700, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Saturday, July 07, 2012 16:54:48 Adam Wilson wrote:
On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.g...@gmx.ch>
wrote:
> The DMD backend is very fast in comparison to other backends.
>
> LLVM is unlikely to catch up in speed, because it is well
architectured
> and more general.
Oh, I agree that it is, but as I've been saying, raw compiler speed is
rarely an important factor outside of small circles of developers, if it
was, businesses would have given up on C++ LONG ago. It's nice to have,
but the business case for it is weak comparatively.
Just because one set of developers has priorities other than compilation
speed
which they consider to be more important doesn't mean that a lot of
developers
don't think that compilation speed is important. I've worked on projects
that
took over 3 hours to build but that doesn't mean that I wouldn't have
wanted
them to be faster. I've known programmers who complained about builds
which
were over a minute!
Sure they complain, but they would complain harder if the generated code
was sub-optimal or had bugs in it. And I imagine that multiple hour build
times are more the exception than rule even in C++, my understanding is
that all 50mloc of Windows can compile overnight using distributed
compiling. Essentially, my argument is that for business compilation time
is something that can be attacked with money, where code generation and
perf bugs are not.
If you rate something else higher than compilation speed, that's fine,
but that
doesn't mean that compilation speed doesn't matter, because it does.
That's been my whole point, we need ways to tell other people about the
pro's and con's of each tool, so that they can choose the right tool,
knowing it's capabilities and limitations. Right now, it's all DMD.
And if the various D Compilers are consistent enough, it arguably
becomes a
good course of action to build your ultimate release using gdc or ldc
but to
do most of the direct development on dmd so that you get a fast
compile-test-
rewrite cycle.
- Jonathan M Davis
Except when you are working on architectures that DMD doesn't support.
Such as Win64, our primary arch here at work. We also want to get into ARM
on Windows. Win32 is fast becoming irrelevant for new work as almost all
Win7 machines shipped these days are x64. Essentially, I cannot justify
DMD under any circumstance for production work here.
However, I realize that for most people Win32 only is just fine. But we
need a page that explains all these differences. As I said in my first
post on the subject, I only know the differences because I've been here
for many months, most decision makers aren't going to dedicate a trivial
fraction of that time. They'll see that DMD doesn't support Win64 and move
on without doing the investigation to find out that there is even an
option for LLVM, because, as near as I can tell, it's not even mentioned.
They may try GDC only to find that it's not well supported on Windows at
all (i've heard mixed reports of people getting builds working and it
seems extremely fragile).
If D is going to use the multiple-tool approach, which I agree it should,
then we should do our best to promote all the tools and more importantly,
the community is actively engaged in supporting and improving all of them.
I am willing to do the website work, but I have no idea when I'll get to
it as I have other D projects cooking, including GSoC; and more
importantly, if I even understand the differences well enough myself to
make accurate statements.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
