On Monday, 1 June 2015 at 21:21:58 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 19:48:01 UTC, weaselcat wrote:
at the risk of sounding like a broken record, if ldc/gdc not
being 2.067 stops a DDMD release due to dmd's generated code
being too slow, maybe it's time to phase dmd out ;)
Given how slow they are at compiling? Not a chance. dmd's speed
is a huge feature.
dmd's speed is fast only in comparison with C++ compilers, go
runs circles around it.
What I would recommend (and have heard others recommend) is
that development normally be done with dmd so that you can get
the fast compile-test-edit cycle that it enables and then use
gdc or ldc when you generate production code so that it'll
actually then be optimized properly. That way, you get fast
production binaries _and_ fast compilation speed where you need
it. But developing code with gdc or ldc would just be painful
in comparison to developing with dmd.
- Jonathan M Davis
it seems like it would be easier to fix LDC's compiling speed
than make a 20-year old ex-C++ backend be able to compete with
LLVM/GCC's codegen.
or else LDC and GDC are going to forever lag behind dmd due to a
lack of manpower, so you have to pick between being able to have
relevant bugfixes, new features, etc from the past ~12-18, or
having code that runs faster than C# on mono.
The way everyone says "just develop with dmd, then use LDC/GDC
for speed!" is ridiculous considering I frequently have to alter
my code to even work with LDC/GDC.
