> sure what you mean. A theoretical compiler doesn't matter; what actual compilers do does.

Of course it does, it defines how far you can go in a concurrent build process before hitting an unsurpassable bottle-neck.

(not that I personally care, as I find both C++ and D compilers to be fast enough)

On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
>> it can get even better if you properly modularize your projects instead of having 1-2 files that build slow, which causes a lot of waiting.
>
> Yes, sure. You can probably get the same build speeds as with C if you organize your code in a particular way or shy away from certain patterns.
>
> What I was talking about was the language, meaning that you don't write your code to give a boost in compilation speed. Clearly possible, but if you use third party frameworks… then you're out of luck.
>
> An analogy: SQL isn't particularly expressive, but the limitations of the language makes it possible to execute it bottom-up. NOSQL engines are even less expressive, but can be even more easily distributed.

ah yes, those famous fast C build times.
Excuse me while I go take half an hour to build GDB.

On Wednesday, 3 June 2015 at 11:35:43 UTC, weaselcat wrote:
> ah yes, those famous fast C build times.
> Excuse me while I go take half an hour to build GDB.

Heh... It is possible to write very fast C compilers with high concurrency in builds, if there is a market for it, but most people want some optimizations too. So that's what people evaluate a compiler by: typical integration builds. Squeaky wheel gets most oil.

On Wednesday, 3 June 2015 at 10:37:24 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo  Pinto wrote:
>> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>>> Project size is irrelevant here. I had 500 line C++ project that took 10 minutes to compile (hello boost::spirit). It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.
>>
>> Even C.
>
> Now really? C was designed at a time where you couldn't even hold the source file in memory, so there is not even a need for an explicit AST.
>
> C can essentially be "streamed" in separate passes: cpp->cc->asm->linking
>
> If compiling C is slow, it is just the compiler or the build system, not the language.

Yes really, specially when comparing with Turbo Pascal, Delphi, Modula-2, Oberon and a few other languages not tied to UNIX linker model.

Multiply that hour times HP-UX (aCC), Solaris (SunPro), Windows (cl), Aix (xlc), Red-Hat Linux (gcc). Which were the systems being used.

As a side note, Visual C++ 2015 will be quite fast.

http://channel9.msdn.com/Events/Build/2015/3-610

They literal have re-done their linker to use a database model and support incremental linking.

Similarly to what IBM did with Visual C++ Code Store and Lucid's Energize.

All the solutions have in common not relying in the traditional UNIX linker model.


--
Paulo

On Wednesday, 3 June 2015 at 12:20:29 UTC, Paulo  Pinto wrote:
> Yes really, specially when comparing with Turbo Pascal, Delphi, Modula-2, Oberon and a few other languages not tied to UNIX linker model.

Yeah, I agree that the implementation for Turbo Pascal was good for the hardware it ran on. But I don't think Pascal as a language is easier to compile fast than C. I think they match up.

> As a side note, Visual C++ 2015 will be quite fast.
>
> http://channel9.msdn.com/Events/Build/2015/3-610
>
> They literal have re-done their linker to use a database model and support incremental linking.

Ok, I don't view linking as part of compilation... I don't think C as a language requires a specific linkage model (only the conceptual compilation units).

On 6/3/15 3:50 AM, Paulo Pinto wrote:
> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>> Project size is irrelevant here. I had 500 line C++ project that took
>> 10 minutes to compile (hello boost::spirit). It is impossible for C++
>> to compile faster than D by design. Any time it seems so you either
>> aren't comparing same thing or get misinformed. Or do straightforward
>> separate compilation.
>
> Even C.
>
> Our project, back when I was doing C in the early 2000's, a "make clean
> all" took around one hour.

It might be possible the processor/RAM constraints were different in 2000 than they are now :)

-Steve

On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer wrote:
> On 6/3/15 3:50 AM, Paulo Pinto wrote:
>> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>>> Project size is irrelevant here. I had 500 line C++ project that took
>>> 10 minutes to compile (hello boost::spirit). It is impossible for C++
>>> to compile faster than D by design. Any time it seems so you either
>>> aren't comparing same thing or get misinformed. Or do straightforward
>>> separate compilation.
>>
>> Even C.
>>
>> Our project, back when I was doing C in the early 2000's, a "make clean
>> all" took around one hour.
>
> It might be possible the processor/RAM constraints were different in 2000 than they are now :)
>
> -Steve

Yeah, some people take 9 hours instead with C++ using modern hardware.

http://www.reddit.com/r/programming/comments/37n39g/john_carmack_shares_his_experiences_with_static/croml2i

If you noticed a later post from me, those systems were UNIX servers, not desktop PCs.

--
Paulo

On 6/3/15 10:19 AM, Paulo Pinto wrote:
> On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer wrote:
>> On 6/3/15 3:50 AM, Paulo Pinto wrote:
>>> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>>>> Project size is irrelevant here. I had 500 line C++ project that took
>>>> 10 minutes to compile (hello boost::spirit). It is impossible for C++
>>>> to compile faster than D by design. Any time it seems so you either
>>>> aren't comparing same thing or get misinformed. Or do straightforward
>>>> separate compilation.
>>>
>>> Even C.
>>>
>>> Our project, back when I was doing C in the early 2000's, a "make clean
>>> all" took around one hour.
>>
>> It might be possible the processor/RAM constraints were different in
>> 2000 than they are now :)
>
> Yeah, some people take 9 hours instead with C++ using modern hardware.
>
> http://www.reddit.com/r/programming/comments/37n39g/john_carmack_shares_his_experiences_with_static/croml2i
>
>
> If you noticed a later post from me, those systems were UNIX servers,
> not desktop PCs.

Sure, but I still think it's difficult to compare systems. Processors just weren't that fast back then. You could have 256 of them, and lots of RAM, but the RAM architecture was slower too.

If your compiler could run in parallel to build, perhaps you could get faster compile times, but it's so difficult to compare these things in an apples-to-apples comparison. Especially when the size/complexity of the program being compiled isn't necessarily analogous.

-Steve

On 3 June 2015 at 13:35, weaselcat via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad wrote:
>
>> On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
>>
>>> it can get even better if you properly modularize your projects instead of having 1-2 files that build slow, which causes a lot of waiting.
>>>
>>
>> Yes, sure. You can probably get the same build speeds as with C if you organize your code in a particular way or shy away from certain patterns.
>>
>> What I was talking about was the language, meaning that you don't write your code to give a boost in compilation speed. Clearly possible, but if you use third party frameworks… then you're out of luck.
>>
>> An analogy: SQL isn't particularly expressive, but the limitations of the language makes it possible to execute it bottom-up. NOSQL engines are even less expressive, but can be even more easily distributed.
>>
>
> ah yes, those famous fast C build times.
> Excuse me while I go take half an hour to build GDB.
>

You're probably doing it wrong and accidentally building all of binutils instead.  Use 'make all-gdb' and enjoy faster builds :-p

On Wednesday, 3 June 2015 at 15:14:47 UTC, Iain Buclaw wrote:
> You're probably doing it wrong and accidentally building all of binutils
> instead.  Use 'make all-gdb' and enjoy faster builds :-p

Or use TCC. :^P