Richard Cownie (tich@pobox.com) on 6/27/10 wrote:
---------------------------
>Mark Roulo (nothanks@xxx.com) on 6/27/10 wrote:
>---------------------------
>
>>However, I also think that C++ inherently takes longer to build than equivalent
>>Java. Two things *should* contribute to this:
>
>Probably true. But I think the real problem is that
>corporate management are often shockingly reluctant to
>invest $20K in capital for a compile farm (10 Nehalems
>with 8 threads each buys you a lot of compile throughput)
>that would give a big boost in productivity to 20
>developers who are costing the company $150K/year each.
>
>So I think the problem of slow compiles is more to do
>with bean-counters than language designers.

I don't understand how you could say that.

I assume you know that the amount of redundancy and inefficient algorithms in current C++ compilers (GCC in particular, as well is in others) is *huge*. Of course, I agree that buying 10 Nehalems will yield the expected result (up to 10x compilation time reduction), but why are you downplaying the importance of compiler architecture and its efficiency? Why?

For example, I don't understand why don't you fully admit that current C/C++ compilers did not really embrace the idea of "precompiled header files". They started to support it long time ago - but then stopped in half-way of the process. So, what we have now is some *mediocre* (at best) implementation of this idea.

... unless someone presents a serious argument why C/C++ compilers cannot be improved I am going to claim that it is possible to develop a C/C++ compiler that is 100x faster than the compilers we are using nowadays and 10000x faster in case of small incremental changes. (And I am *not* talking about using 100 Nehalems.)