Re: Reducing build-times for large projects.
From: Andre Kostur (nntpspam_at_kostur.net)
Date: 03/09/05
- Next message: Karl Heinz Buchegger: "Re: Derived classes question"
- Previous message: Andre Kostur: "Re: std::map - erase+continue"
- In reply to: Phil Staite: "Re: Reducing build-times for large projects."
- Next in thread: Andre Kostur: "Re: Reducing build-times for large projects."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 09 Mar 2005 16:24:49 GMT
Phil Staite <phil@nospam.com> wrote in
news:nsednapVbKmBIbPfRVn-gA@pcisys.net:
> DHOLLINGSWORTH2 wrote:
>> 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!
>
> We're talking about the code for the function, not the code that leads
> up to the function. You either have multiple calls to one set of
> instructions, or just that set of instructions plonked down in the
> instruction stream in multiple places. (ie you've replaced your calls
> with the code)
However, by "plonking down" the code, you give the optimizer more to work
with....
> In the non-inlined case you may get lucky and only fetch the call
> instruction from main memory, then hit in the cache for the actual
> function's instructions.
>
> In the case of inlined code, you may get luck and hit the cache for
> the inlined code too - just as in the non-inlined case.
>
> However, I would contend that it is simple probability that if there
> is only one copy of the code used by all the places that reference it,
> that is far more likely to be in cache than one particular instance
> out of many inlined copies. Also that one copy of the function's code
> is less likely to push other things out of the cache (that you may
> later want back) than N copies of the same code, from different
> addresses.
Except (as I mentioned in another post) if your function setup and
teardown code is larger than the actual code within the inlined function,
then you are increasing the code size at the call point and thus
increasing the probabilities of your other function being pushed out of
cache (hey... if we're talking probablilities....)
Or.. if your inlined function is executed within a loop (let's assume
something along the lines of: for (int i = 0; i < 1000000; ++i) someFn
(i);
If someFn() isn't inlined, then you'd have to pay for the 1000000
call/return to someFn. If someFn is inlined, then perhaps the first 90%
of someFn works out to be a loop invariant and the optimizer pulls all of
that code out in front of the loop, and only executes the remaining 10%
of the code 1000000 times. (Of course this depends on your optimizer)
[snip]
> But this whole discussion is just barely anchored in reality. An
> awful lot depends on real world parameters that vary widely and wildy
> from system to system, program to program. I was just trying to point
> out to the OP that when testing reveals something that makes you say
> "Oh {explative}! How'd that happen?" you've got to be ready to
> challenge your assumptions. One common assumption is that inlining
> improves execution speed. It may, but then again, it may not.
Next common assumption... marking a function as inline doesn't
necessarily mean that it will be inlined.
As usual, beware of making sweeping generalizations.
- Next message: Karl Heinz Buchegger: "Re: Derived classes question"
- Previous message: Andre Kostur: "Re: std::map - erase+continue"
- In reply to: Phil Staite: "Re: Reducing build-times for large projects."
- Next in thread: Andre Kostur: "Re: Reducing build-times for large projects."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
