On Tuesday, 10 December 2013 at 21:28:41 UTC, Paulo Pinto wrote:
> Those are implementation issues, right?

Yeah, a lot of the blame can be placed on the intertwined phobos modules. D without phobos is a lot faster to compile (and produces significantly smaller exes).

On Tue, Dec 10, 2013 at 10:52:10PM +0100, Adam D. Ruppe wrote:
> On Tuesday, 10 December 2013 at 21:28:41 UTC, Paulo Pinto wrote:
> >Those are implementation issues, right?
> 
> Yeah, a lot of the blame can be placed on the intertwined phobos modules. D without phobos is a lot faster to compile (and produces significantly smaller exes).

That's why I proposed reducing Phobos interdependencies. Didn't sound like it caught on, though. :-(


T

-- 
This sentence is false.

On Tuesday, 10 December 2013 at 21:39:12 UTC, H. S. Teoh wrote:
> One of my template-heavy projects take almost 10 seconds to compile just a single source file.

Always compile all your D files at once, that's my tip, otherwise you'll pay that cost every time the file is imported!

But yeah, my work app can take up to a full minute to compile, lots of ctfe there. D can be super fast, but can also be slow with the current  impl.

Am Tue, 10 Dec 2013 22:16:25 +0100
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote:
> > At the least, it'll compile a lot faster!
> 
> Small C programs compile a *lot* faster than small D programs that use Phobos.
> 
> import std.stdio; == add half a second to your compile time.
> 
> $ time dmd hellod.d
> 
> real    0m0.780s # YIKES!
> user    0m0.649s
> sys     0m0.102s
> 
> $ time gcc helloc.c
> 
> real    0m0.148s # not bad
> user    0m0.095s
> sys     0m0.039s
> 
> 
> yikes, even doing printf in D is slow nowadays
> 
> $ time dmd hellod.d
> 
> real    0m0.290s # good but not great
> user    0m0.212s
> sys     0m0.058s
> 
> 
> 
> Larger D programs do better, of course, at least if you compile all the files at once (and don't use so much CTFE that it starts thrashing the swap file).

Isn't it fairer to compile only (-c):

dmd -c std_stdio.d  0,30s user 0,07s system 99% cpu 0,374 total dmd -c printf.d     0,00s user 0,00s system 87% cpu 0,008 total gcc -c printf.c     0,02s user 0,01s system 93% cpu 0,031 total

-- 
Marco

On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote:
>
> "there is no way proper C code can be slower than those languages."

Didn't Bjarne cover this in his C++ performance talk at SD West in 2007?  Templates alone can make C++ and D code faster than even hand-optimized C.  And that doesn't even consider some of the other points you mentioned.

On 12/10/2013 07:26 PM, Walter Bright wrote:
> On 12/10/2013 1:58 AM, Timon Gehr wrote:
>> Recovering all immutable and const qualifiers that are possible to
>> assign to the program is simple to do if the whole program is available.
>
> I believe you are seriously mistaken about it being simple, or even
> possible.
>...

Unfortunately I'm not currently in a position to invest any time into implementing mutability analysis for C code. Maybe later. It might prove interesting to see how well a straightforward inference of D-style qualifiers works for existing code bases. (But this is not the relevant question here since we are talking about _inherent_ advantages.)

> For example, malloc() returns a pointer. How do you know if that returns
> a pointer to immutable data or not? Even if it could look at the source
> code to malloc()?
>

Malloc is part of the language runtime. Everything needed is known about it, in particular that it is pure (in the D sense). Also, the source code of malloc will not be standard C code.

In any case, please understand that giving even a valid example of a case where such an approach cannot do well (e.g. all variables under consideration are actually mutated) does not invalidate the statement made.

On 12/10/2013 3:04 PM, Timon Gehr wrote:
> Malloc is part of the language runtime. Everything needed is known about it, in
> particular that it is pure (in the D sense). Also, the source code of malloc
> will not be standard C code.

All right, so write your own storage allocator. How are you going to tell the C compiler that it's pure?

> In any case, please understand that giving even a valid example of a case where
> such an approach cannot do well (e.g. all variables under consideration are
> actually mutated) does not invalidate the statement made.

Pointers coming from things like allocators and data structures where no known compiler technoloty could deduce what is happening in it are the norm, not the exception.

On 12/10/2013 1:37 PM, H. S. Teoh wrote:
> That's not too bad. One of my template-heavy projects take almost 10
> seconds to compile just a single source file. And a single string import
> can add up to 3-4 seconds (well, probably due to CTFE since I call
> split() on the string).

That isn't C-style code.

The issue is convenience of writing C code in D vs C.

On 12/10/2013 3:23 PM, Marco Leise wrote:
> Isn't it fairer to compile only (-c):
>
> dmd -c std_stdio.d  0,30s user 0,07s system 99% cpu 0,374 total
> dmd -c printf.d     0,00s user 0,00s system 87% cpu 0,008 total
> gcc -c printf.c     0,02s user 0,01s system 93% cpu 0,031 total

Yup, since gcc is not statically linking with the C runtime library, but dmd is statically linking to Phobos.

On Tue, Dec 10, 2013 at 03:48:51PM -0800, Walter Bright wrote:
> On 12/10/2013 1:37 PM, H. S. Teoh wrote:
> >That's not too bad. One of my template-heavy projects take almost 10 seconds to compile just a single source file. And a single string import can add up to 3-4 seconds (well, probably due to CTFE since I call split() on the string).
> 
> That isn't C-style code.
> 
> The issue is convenience of writing C code in D vs C.

So you're trying to say that it's easier to write C code in D, rather than in C?

I thought this thread was about the inherent advantages of D over C. And I agree that D has a lot of advantages, but it would be a lie to say that there are no disadvantages.


T

-- 
All problems are easy in retrospect.