Hi,
Now, I do not follow what/where this thread is going.
The orignal post described how the kernel had got much larger.
I replied adding observations on the compiler requirements having
increased dramatically.
on the size of graphical applications.
Is that a whinge? Nope. That is additional evidence for the comment that
things are growing in size.
yes, you say, buy more ram. Well yes, but that compiler version change I
am referring to happened in 2000 (from memory) and ram was much more
expensive than currently.
Now, we have moved to idle speculation on how much improvement there was
in the final library. The compiler version changed from 2.95 to 2.96,
which suggests there will not be a significant improvement in performance.
Was the code twice as fast? Nope. similar speed would be my estimate.
Derek.
On Wed, 23 Nov 2005, Volker Kuhlmann wrote:
> > steps a) and b) used the same library. So it is not an increase in the
> > library size.
>
> Ok
>
> > The crucial thing was that the compiler was significantly
> > change soas to require more ram to compile the test library.
>
> Sure, you expect that, and I outlined some possible reasons. Now some
> facts please about the resulting code when compiled with the new
> compiler instead of the old one, or else please stop whinging. If the
> code now runs twice as fast at 80% of its size but compiling the source
> takes 4x as much RAM, I count that as a significant improvement of gcc.
> No doubt there's a switch to turn it off again. If you don't like it,
> use the old compiler. But it's all speculation of course until you
> answer these relevant questions (which you should have done together
> with your first complaint about gcc). I find it hard to believe that the
> gcc team would quadruple the resource requirements of their software for
> zero gain.
>
> You seem to be measuring bloat by its cost, but it seems better to me to
> define bloat as gain divided by cost.
>
> > But if the library is much bigger, there will be more cache misses in the
> > CPU.
>
> s/library/code/
>
> What are you talking about here? The compiler? Your library code? And
> code speed and efficiency is not easily assessable or predictable these
> days, by the way.
>
> Volker
>
>
--
Derek Smithies Ph.D. Any fool can write code that
IndraNet Technologies Ltd. a computer can understand.
Email: [EMAIL PROTECTED] Good programmers write code
ph +64 3 365 6485 that humans can understand.
Web: http://www.indranet-technologies.com/ Martin Fowler
