Prev: How to reuse an existing stream with a different streambuf ?
Next: A quick question about Initializer-List in C++0x
From: Hakusa on 14 Jun 2010 18:03 On Jun 14, 4:23 am, Nick Hounsome <nick.houns...(a)gmail.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. > > A C++ compiler can never know this since it only ever sees one > compilation unit. With the notable exception of whole program optimization. I believe MSVC offers this, and a branch of gcc. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 14 Jun 2010 18:03 Nick Hounsome wrote: > On 13 June, 21:43, Peter Olcott <NoS...(a)OCR4Screen.com> 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. >> (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. > > A C++ compiler can never know this since it only ever sees one > compilation unit. Yes it can if the programmer remembers to declare the function static. It can also usually know it if the function is declared in the unnamed namespace (though exported templates can sometimes break that.) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 14 Jun 2010 18:01 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). > (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) > (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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 14 Jun 2010 18:04 On 6/14/2010 3:23 AM, Vaclav Haisman 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. My reasoning is correct. Inline expansion of a single function call reduces code size by the amount of the function call overhead. The only possible way for inline expansion to increase code size requires more than a single function call. In some cases (where the function call overhead takes more room than the function body) inline expansion reduces the code size of multiple function calls. > >> >>> >>> http://en.wikipedia.org/wiki/Inline_expansion >>> >>> for a brief summary and vocabulary starting point. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: C. M. Heard on 14 Jun 2010 18:19
On Mon, 14 Jun 2010, Vaclav Haisman wrote: > Peter Olcott wrote, On 13.6.2010 22:43: > > (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. Hmm. I didn't see anything in the Problems sections of http://en.wikipedia.org/wiki/Inline_expansion that could possibly apply to a function that is called only once. Perhaps you could point out what I (and Peter Olcott) missed. C. M. Heard -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |