Re: Reducing build-times for large projects.
From: DHOLLINGSWORTH2 (DHOLLINGSWORTH2_at_cox.net)
Date: 03/09/05
- Next message: DHOLLINGSWORTH2: "Re: Pointer List How?"
- Previous message: beerrock: "Re: Small C++ exercise"
- In reply to: Jason Heyes: "Re: Reducing build-times for large projects."
- Next in thread: Phil Staite: "Re: Reducing build-times for large projects."
- Reply: Phil Staite: "Re: Reducing build-times for large projects."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 9 Mar 2005 01:53:48 -0600
I'm sorry, but Inline functions are loaded right along with the rest of the
code. If the line before it executed, then the very next inline code has
already been loaded.
You are correct that not loading code is faster than loading and waiting for
it to execute. The argument is like saying dont push the BP becuase the
actual code to Push the BP has to be loaded, SO DOES THE F"N CODE TO CALL
THE FUNCTION THAT IS ALREADY IN CACHE!
and it don't have to load as much inline, as it does using the stack.
LOOP unrolling has been going on for years. and its a lot faster loading
that same chunk of code over and over than staying in the same spot doing
all of the compares.
If, however you don't like inline, you can also use register calling, which
the compiler can streamline to gain even more speed. The difference between
that and inline is a CALL [addr];
"Jason Heyes" <jasonheyes@optusnet.com.au> wrote in message
news:422e995e$0$6161$afc38c87@news.optusnet.com.au...
> "Phil Staite" <phil@nospam.com> wrote in message
> news:422E882E.4030702@nospam.com...
>> Jason Heyes wrote:
>>>
>>> Inline functions go away as compile-time dependencies are minimised. Do
>>> you see this as an issue worth worrying about? Will program performance
>>> be compromised in favour of compilation speed?
>>
>> Actually, there's some evidence that inline functions can *hurt* program
>> performance. Consider, any reasonably fast CPU will have a clock speed
>> far in excess of main memory's ability to keep up. Hence instruction
>> cache is king in terms of performance. Cache "misses" mean wait states
>> while awaiting a fetch from main memory.
>>
>> Now consider a reasonably heavily used, short function. (eg. accessor
>> functions for protected/private data come to mind) Sounds like a great
>> candidate for inlining, right? But inlining puts a copy of that code
>> (admittedly small) at N different addresses in the executable code.
>> Whereas a non-inlined function has one copy, at one address. So if the
>> cache is big enough, and the program stays local enough, the non-inlined
>> copy may stay in cache most or all of the time. Meanwhile, the inlined
>> code, being at unique addresses, must be fetched each time it is needed
>> from main memory.
>>
>> Depending on a lot of other factors, it is not beyond the realm of
>> possibility that the non-inlined code is faster, since a cache hit for
>> the code would outweigh the penalty of a call/return. While the penalty
>> for a cache miss might outweigh the benefit of avoiding a call/return.
>>
>> The upshot of this little thought experiment is the same old song: Don't
>> ever assume X is better than Y in terms of performance. Always, always
>> always test to see the real story on your cpu, OS, compiler, program, and
>> data set... The corallary is, make it work first, then make it work
>> fast. Of course that's not a license to choose explicitly stupid
>> algorithms, data structures, and program structure. ;-)
>>
>
> Ok. Thanks dude.
>
- Next message: DHOLLINGSWORTH2: "Re: Pointer List How?"
- Previous message: beerrock: "Re: Small C++ exercise"
- In reply to: Jason Heyes: "Re: Reducing build-times for large projects."
- Next in thread: Phil Staite: "Re: Reducing build-times for large projects."
- Reply: Phil Staite: "Re: Reducing build-times for large projects."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
