Daily downloads in decline

weaselcat via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 1 15:43:57 PDT 2015


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.


More information about the Digitalmars-d mailing list