Critique of code quality
in [C++]
|
Prev: How to reuse an existing stream with a different streambuf ?
Next: A quick question about Initializer-List in C++0x
From: Peter Olcott on 15 Jun 2010 04:59 On 6/15/2010 3:59 AM, Ulrich Eckhardt wrote: > Nick Hounsome wrote: >> A C++ compiler can never know this [how often a function is used] since it >> only ever sees one compilation unit. > > So-called "whole program optimization" has existed now for a long time in > many compilers, so that statement is not actually accurate any longer. > > That said, the OP should just use that optimisation, since his compiler > supports it, and stop trying to outsmart the compiler. > > Uli > Although it may be possible for the compiler to inline a function without inline being requested I am not sure that it typically does this. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 15 Jun 2010 05:04 On 6/15/2010 4:18 AM, Joshua Maurice wrote: > On Jun 14, 1:23 am, Vaclav Haisman<v.hais...(a)sh.cvut.cz> wrote: >> Peter Olcott wrote, On 13.6.2010 22:43:>[...] >>>> In those absolute terms that statement is flat wrong. Whether to >>>> inline depends intimately on the relative execution frequency and >>>> size of the code in question versus code in the calling chain. It >>>> has to do with optimizing instruction cache performance and other >>>> factors. See the "Problems" section in the wikipedia >> >>> (1) The ONLY reason not to always inline everything (that can be in-lined) >>> all the time is code bloat. >>> (2) If a function is only called once then there can not possibly be any code >>> bloat at all. >>> (3) Therefore all functions that are only called once should always be in-lined. >> >> You have completely ignored the Problems section of the Wikipedia page. Your >> "reasoning" above is wrong. >> >>>> http://en.wikipedia.org/wiki/Inline_expansion >> >>>> for a brief summary and vocabulary starting point. > > It appears as though the only "real" "problem" which he ignored is: > >> The increase in code size may cause a small, critical section of code to no longer fit in the cache, causing cache misses and slowdown. > > Specifically, let's consider a function f which calls a function g, > but not always. g is called from f in a conditional body. Let's > further suppose that this is the uncommon path. Expanding inline g > into f could greatly increase the size of f, causing greater > instruction cache misses for relatively small gains (under the > assumption that the g branch is an infrequent path). Thus Peter > Olcott, your premise (1) is false, and thus your argument is not > sound. > > I was not referring to the case of conditional execution. You pointed out a valid counter-example to my overly broad statement. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 15 Jun 2010 05:01 On 6/15/2010 4:17 AM, Asher Langton wrote: > On Jun 13, 1:43 pm, Peter Olcott<NoS...(a)OCR4Screen.com> wrote: >> (1) The ONLY reason not to always inline everything (that can be >> in-lined) all the time is code bloat. >> (2) If a function is only called once then there can not possibly be any >> code bloat at all. >> (3) Therefore all functions that are only called once should always be >> in-lined. > > Consider this snippet: > > while (...) > { > ... > if (condition) > doSomething(); > } > > If doSomething() is inlined, then the body of the loop might no longer > fit in the instruction cache, which -- in the case where 'condition' If the body of the loop without the function call overhead does not fit in cache, then the body of the loop with the function call overhead will also not fit in cache because it requires even more memory. Adding function call overhead can not reduce memory requirements. > is unlikely to be true -- could cause a significant decrease in > performance. Contrary to your claim, doSomething() might only be > called once, yet it would not make sense to inline this function call. > > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 15 Jun 2010 05:04 On 6/15/2010 9:11 AM, Nick Hounsome wrote: > On 15 June, 09:59, Ulrich Eckhardt<eckha...(a)satorlaser.com> wrote: >> Nick Hounsome wrote: >>> A C++ compiler can never know this [how often a function is used] since it >>> only ever sees one compilation unit. >> >> So-called "whole program optimization" has existed now for a long time in >> many compilers, so that statement is not actually accurate any longer. > > I think that this is actually only "whole exe/dll optimization". > When an app consists of a small exe and many dlls (as most real apps > do) the optimization doesn't extend across these (unless you have a > virtual machine type system such as .NET or Java) > > What I have read of VS 2010 suggests that it only does it in > restricted circumstances. > >> That said, the OP should just use that optimisation, since his compiler >> supports it, and stop trying to outsmart the compiler. > > Indeed - As I said the system is allowed to inline even if the inline > keyword is not present > > But how often does it actually do this? I would estimate that specifying that inline is desired results in in-lined functions more often than when it is not explicitly requested. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 15 Jun 2010 05:00
On 6/15/2010 4:01 AM, Francis Glassborow wrote: > Peter Olcott wrote: >> On 6/13/2010 5:06 AM, Keith H Duggar wrote: >>> On Jun 12, 2:12 am, Peter Olcott<NoS...(a)OCR4Screen.com> wrote: >>>> Inlining is always better for functions that are known >>>> to only need to be called from a single place. >>> >>> In those absolute terms that statement is flat wrong. Whether to >>> inline depends intimately on the relative execution frequency and >>> size of the code in question versus code in the calling chain. It >>> has to do with optimizing instruction cache performance and other >>> factors. See the "Problems" section in the wikipedia >> >> (1) The ONLY reason not to always inline everything (that can be >> in-lined) all the time is code bloat. > > That might be true on a machine where all memory was equal but on real > world machines where we have multiple levels of cache memory as well as > paging to backing store bloat can also result in reduced speed > (sometimes a very significant reduction). If a function is called only once, this results in a net reduction in total memory. A net reduction in total memory would tend to reduce the need for all of the various types of memory, and not ever increase the use of any of this memory. > >> (2) If a function is only called once then there can not possibly be any >> code bloat at all. > > Then the function should be declared as static as that will reduce the > chances of added calls being aded behind the compiler's back (i.e. in > other TU's) Some of these functions (the way it is currently coded) require the use of member data. I would estimate that it may be the case that many times a net increase in total speed would occur even if the function is called more than once. If in these separate invocations the function is called in a tight loop, then even multiple inlined function calls could increase speed. > >> (3) Therefore all functions that are only called once should always be >> in-lined. > > If raw performance were the only issue. however in practice that is > rarely the case. Inlining causes potential maintenance problems. > I don't see how either adding or removing the "inline" keyword would change maintainability at all. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |