I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp Who do I need to contact to make this happen?
On 09/10/2011 18:34, John Maddock wrote:
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
Who do I need to contact to make this happen?
John is the maintainer.
Right, care to supply a patch?
Patch attached.
Le 10/10/11 18:51, Mathias Gaunard a écrit :
On 09/10/2011 18:34, John Maddock wrote:
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
Who do I need to contact to make this happen?
John is the maintainer.
Right, care to supply a patch?
Patch attached.
I don't know if the better place to define these macros is in the suffix.hpp file. This file is intendeed to define macros that can be defined independently of compiler versions or platforms. IMO the good place is to include them in the specific compiler file, and define them as empty in suffix if not already defined. boost/config/suffix.hpp #if !defined(BOOST_FORCEINLINE) #define BOOST_FORCEINLINE inline #endif boost/config/compiler/gcc.hpp # if defined(__GNUC__)&& __GNUC__> 3 # define BOOST_FORCEINLINE inline __attribute__ ((always_inline)) # endif boost/config/compiler/visualc.hpp # define BOOST_FORCEINLINE __forceinline Best, Vicente
On 10/10/2011 09:03 PM, Vicente J. Botet Escriba wrote:
I don't know if the better place to define these macros is in the suffix.hpp file. This file is intendeed to define macros that can be defined independently of compiler versions or platforms. IMO the good place is to include them in the specific compiler file, and define them as empty in suffix if not already defined.
boost/config/suffix.hpp
#if !defined(BOOST_FORCEINLINE) #define BOOST_FORCEINLINE inline #endif
boost/config/compiler/gcc.hpp
# if defined(__GNUC__)&& __GNUC__> 3 # define BOOST_FORCEINLINE inline __attribute__ ((always_inline)) # endif
boost/config/compiler/visualc.hpp
# define BOOST_FORCEINLINE __forceinline
Those macros are for compilers that behave like GCC and those that behave like MSVC, and are not restricted to the real GCC or MSVC; I don't know if placing them in those files will be enough. Also, it seems to me those files are only used for the BOOST_NO_XXX family of macros.
Le 10/10/11 23:27, Mathias Gaunard a écrit :
On 10/10/2011 09:03 PM, Vicente J. Botet Escriba wrote:
I don't know if the better place to define these macros is in the suffix.hpp file. This file is intendeed to define macros that can be defined independently of compiler versions or platforms. IMO the good place is to include them in the specific compiler file, and define them as empty in suffix if not already defined.
boost/config/suffix.hpp
#if !defined(BOOST_FORCEINLINE) #define BOOST_FORCEINLINE inline #endif
boost/config/compiler/gcc.hpp
# if defined(__GNUC__)&& __GNUC__> 3 # define BOOST_FORCEINLINE inline __attribute__ ((always_inline)) # endif
boost/config/compiler/visualc.hpp
# define BOOST_FORCEINLINE __forceinline
Those macros are for compilers that behave like GCC and those that behave like MSVC, and are not restricted to the real GCC or MSVC; I don't know if placing them in those files will be enough.
Also, it seems to me those files are only used for the BOOST_NO_XXX family of macros.
I don't know exactly what was exactly the philosophy and if it is only for NO_XXX macros. IMO, modifying the suffix.hpp file each time we know about a new compiler/version that could implement BOOST_FORCEINLINE in some way is not a good approach. Specificities of the compiler should go the the specific compiler.name.hpp file. Of course this is not really important. and I can live with it. Best, Vicente
On Mon, Oct 10, 2011 at 12:51 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 09/10/2011 18:34, John Maddock wrote:
I would like a BOOST_FORCE_INLINE macro to be added to
boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
Who do I need to contact to make this happen?
John is the maintainer.
Right, care to supply a patch?
Patch attached.
I just wanted to point out the existing GIL_FORCEINLINE found in gil_config.hpp, in case others weren't aware of it. Cheers! Andrew Hundt
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
Who do I need to contact to make this happen?
John is the maintainer.
Right, care to supply a patch?
Patch attached.
Applied, thanks. John.
Mathias Gaunard wrote:
On 09/10/2011 18:34, John Maddock wrote:
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
Who do I need to contact to make this happen?
John is the maintainer.
Right, care to supply a patch?
Patch attached.
Despite the name shown above, the patch is for BOOST_FORCEINLINE. Since "force" and "inline" are distinct words, I think the name should be "BOOST_FORCE_INLINE". (Now's the time to change it!) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 11/10/2011 21:05, Stewart, Robert wrote:
Despite the name shown above, the patch is for BOOST_FORCEINLINE. Since "force" and "inline" are distinct words, I think the name should be "BOOST_FORCE_INLINE". (Now's the time to change it!)
I decided to change it to BOOST_FORCEINLINE because a search revealed it was a more frequent name for this kind of macro.
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
On Sun, Oct 9, 2011 at 12:34 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
What compilers provide support? Do they spell it the same way? --Beman
Beman Dawes wrote:
On Sun, Oct 9, 2011 at 12:34 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
What compilers provide support? Do they spell it the same way?
--Beman
If one compiler spells it as '__forceinline', while another calls it 'always_inline', I'd suggest naming the macro 'BOOST_FORCE_ALWAYS_INLINE'. My 2 cents, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
On 10/09/2011 06:56 PM, Beman Dawes wrote:
On Sun, Oct 9, 2011 at 12:34 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
What compilers provide support? Do they spell it the same way?
MSVC has __forceinline, GCC has __attribute((always_inline)), which other compilers probably have as well (at least XL C/C++ seems to support the same syntax as GCC).
On 10/9/2011 12:52 PM, Mathias Gaunard wrote:
On 10/09/2011 06:56 PM, Beman Dawes wrote:
On Sun, Oct 9, 2011 at 12:34 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
What compilers provide support? Do they spell it the same way?
MSVC has __forceinline, GCC has __attribute((always_inline)), which other compilers probably have as well (at least XL C/C++ seems to support the same syntax as GCC).
Do all compilers that support the directive expect it in the same place? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 10/09/2011 11:31 PM, Eric Niebler wrote:
On 10/9/2011 12:52 PM, Mathias Gaunard wrote:
On 10/09/2011 06:56 PM, Beman Dawes wrote:
On Sun, Oct 9, 2011 at 12:34 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2011 04:57 PM, Vicente J. Botet Escriba wrote:
Le 09/10/11 15:30, Mathias Gaunard a écrit :
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
What do you want BOOST_FORCE_INLINE to be replaced for?
As the name suggests, __forceinline or __attribute__((always_inline))
What compilers provide support? Do they spell it the same way?
MSVC has __forceinline, GCC has __attribute((always_inline)), which other compilers probably have as well (at least XL C/C++ seems to support the same syntax as GCC).
Do all compilers that support the directive expect it in the same place?
They're slightly different: __forceinline works just like the normal inline specifier, while __attribute__((always_inline)) can be placed in various places like other GCC attributes, but only has an effect if the function is also inline. So basically it should be something along the lines of #if defined __GNUC__ #define BOOST_FORCE_INLINE __attribute__((always_inline)) inline #elif defined BOOST_MSVC #define BOOST_FORCE_INLINE __forceinline #else #define BOOST_FORCE_INLINE inline #endif
On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
They're slightly different: __forceinline works just like the normal inline specifier, while __attribute__((always_inline)) can be placed in various places like other GCC attributes, but only has an effect if the function is also inline.
Shouldn't the decision to inline be left to the compiler? Olaf
On 10/10/2011 02:02 AM, Olaf van der Spek wrote:
On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
They're slightly different: __forceinline works just like the normal inline specifier, while __attribute__((always_inline)) can be placed in various places like other GCC attributes, but only has an effect if the function is also inline.
Shouldn't the decision to inline be left to the compiler?
The point of that macro is to override the compiler analysis. Compilers are not perfect, so it is beneficial to mark to functions inline manually for a variety of reasons: - you'll get an error or warning if the compiler cannot inline it - you can still get the inlining in debug mode, which can be necessary to make applications that depend a lot on meta-programming to run at acceptable performance - compiling for size is not always very aggressive with inlining, but a lot of meta-programming things rely a lot on aggressive inlining to happen - for codebases with a lot of forwarding the compiler can easily get confused - inlining doesn't seem to take into account the costs of register spilling required by a function call, which is important to avoid in low-level code. Do people generally agree it is ok to add this in Boost.Config, and maybe make some key libraries use it?
On Sun, Oct 9, 2011 at 8:51 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/10/2011 02:02 AM, Olaf van der Spek wrote:
On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
They're slightly different: __forceinline works just like the normal inline specifier, while __attribute__((always_inline)) can be placed in various places like other GCC attributes, but only has an effect if the function is also inline.
Shouldn't the decision to inline be left to the compiler?
The point of that macro is to override the compiler analysis.
Compilers are not perfect, so it is beneficial to mark to functions inline manually for a variety of reasons:
- you'll get an error or warning if the compiler cannot inline it - you can still get the inlining in debug mode, which can be necessary to make applications that depend a lot on meta-programming to run at acceptable performance - compiling for size is not always very aggressive with inlining, but a lot of meta-programming things rely a lot on aggressive inlining to happen - for codebases with a lot of forwarding the compiler can easily get confused - inlining doesn't seem to take into account the costs of register spilling required by a function call, which is important to avoid in low-level code.
Do people generally agree it is ok to add this in Boost.Config, and maybe make some key libraries use it?
Shouldn't there be documentation that describes when to use it and when not to use it? I guess my main concern is that it might be used inappropriately if the name is the only guideline developers have. --Beman
On Sun, Oct 9, 2011 at 6:08 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Oct 9, 2011 at 8:51 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/10/2011 02:02 AM, Olaf van der Spek wrote:
On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
They're slightly different: __forceinline works just like the normal inline specifier, while __attribute__((always_inline)) can be placed in
various
places like other GCC attributes, but only has an effect if the function is also inline.
Shouldn't the decision to inline be left to the compiler?
The point of that macro is to override the compiler analysis.
Compilers are not perfect, so it is beneficial to mark to functions inline manually for a variety of reasons:
- you'll get an error or warning if the compiler cannot inline it - you can still get the inlining in debug mode, which can be necessary to make applications that depend a lot on meta-programming to run at acceptable performance - compiling for size is not always very aggressive with inlining, but a lot of meta-programming things rely a lot on aggressive inlining to happen - for codebases with a lot of forwarding the compiler can easily get confused - inlining doesn't seem to take into account the costs of register spilling required by a function call, which is important to avoid in low-level code.
Do people generally agree it is ok to add this in Boost.Config, and maybe make some key libraries use it?
Shouldn't there be documentation that describes when to use it and when not to use it? I guess my main concern is that it might be used inappropriately if the name is the only guideline developers have.
+1, my thoughts exactly, Beman. Can anyone provide any links to a case study or something similar investigating the effects of forcing inlining? I'm definitely interested to see what real effects this could have. - Jeff
On 10.10.2011. 8:22, Jeffrey Lee Hellrung, Jr. wrote:
+1, my thoughts exactly, Beman. Can anyone provide any links to a case study or something similar investigating the effects of forcing inlining? I'm definitely interested to see what real effects this could have.
Well Mathias has already outlined the major reasons. That seems like quite sufficient documentation. If a developer is performance conscious and notices one the outlined problems in the codegen he can simply try the force inline approach and see if it helps. I don't see where a problem could lie there or a reason for wasting too much time discussing something so simple. Otherwise one could question any existing part of the language by pointing that it could be abused (unintentionally or otherwise). I don't know of a "study" related to forceinline, but in this case it arose as a (partial) solution to the problems listed by Mathias in the development of the NT2 (and thuse Boost.SIMD and Boost.Dispatch) libraries. These were discussed on the NT2 dev mailing list an on #nt2 so maybe someone can present logs of these discussions if you are interested... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On 10/10/2011 10:46, Domagoj Saric wrote:
On 10.10.2011. 8:22, Jeffrey Lee Hellrung, Jr. wrote:
+1, my thoughts exactly, Beman. Can anyone provide any links to a case study or something similar investigating the effects of forcing inlining? I'm definitely interested to see what real effects this could have.
Well Mathias has already outlined the major reasons. That seems like quite sufficient documentation. If a developer is performance conscious and notices one the outlined problems in the codegen he can simply try the force inline approach and see if it helps. I don't see where a problem could lie there or a reason for wasting too much time discussing something so simple. Otherwise one could question any existing part of the language by pointing that it could be abused (unintentionally or otherwise).
I don't know of a "study" related to forceinline, but in this case it arose as a (partial) solution to the problems listed by Mathias in the development of the NT2 (and thuse Boost.SIMD and Boost.Dispatch) libraries. These were discussed on the NT2 dev mailing list an on #nt2 so maybe someone can present logs of these discussions if you are interested...
Boost.SIMD is particularly sensitive to inlining. The arguments of each function should be put into SSE registers, but when a function is not inlined, the registers are copied to the stack and the addresses on the stack are passed to the function. The ABI forces this behaviour because the types used to represent the registers are structures. On another note, inlining stuff has proven useful to ignore a certain amount of function jumping with Boost.Dispatch when running code in a debugger.
On Mon, Oct 10, 2011 at 2:32 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 10/10/2011 10:46, Domagoj Saric wrote:
On 10.10.2011. 8:22, Jeffrey Lee Hellrung, Jr. wrote:
+1, my thoughts exactly, Beman. Can anyone provide any links to a case study or something similar investigating the effects of forcing inlining? I'm definitely interested to see what real effects this could have.
Well Mathias has already outlined the major reasons. That seems like quite sufficient documentation. If a developer is performance conscious and notices one the outlined problems in the codegen he can simply try the force inline approach and see if it helps. I don't see where a problem could lie there or a reason for wasting too much time discussing something so simple. Otherwise one could question any existing part of the language by pointing that it could be abused (unintentionally or otherwise).
I don't know of a "study" related to forceinline, but in this case it arose as a (partial) solution to the problems listed by Mathias in the development of the NT2 (and thuse Boost.SIMD and Boost.Dispatch) libraries. These were discussed on the NT2 dev mailing list an on #nt2 so maybe someone can present logs of these discussions if you are interested...
Boost.SIMD is particularly sensitive to inlining.
The arguments of each function should be put into SSE registers, but when a function is not inlined, the registers are copied to the stack and the addresses on the stack are passed to the function.
The ABI forces this behaviour because the types used to represent the registers are structures.
On another note, inlining stuff has proven useful to ignore a certain amount of function jumping with Boost.Dispatch when running code in a debugger.
Don't get me wrong, I'm sure it's necessary from time to time! Just looking to see what additional wisdom the Boost community can impart regarding its use. Thanks for the follow-ups, - Jeff
Den 10-10-2011 08:22, Jeffrey Lee Hellrung, Jr. skrev:
On Sun, Oct 9, 2011 at 6:08 PM, Beman Dawes<bdawes@acm.org> wrote:
Shouldn't there be documentation that describes when to use it and when not to use it? I guess my main concern is that it might be used inappropriately if the name is the only guideline developers have.
+1, my thoughts exactly, Beman. Can anyone provide any links to a case study or something similar investigating the effects of forcing inlining? I'm definitely interested to see what real effects this could have.
I don't have a link, but can talk a little about my experience. I was trying to optimize some of our performance critical code. Step one is to find the bottlenecks with some tool. I used the one that comes with visual C++. After running this, I had a great overview over which functions took up most of the time, and which functions that were called a lot (say, many million times). Usually, the compiler will not inline a large function because the saved time is neglible and more code is generated. However, the compiler can usually not know that a large function often returns quickly where large parts of the code of the function is only used sometimes. Hence I used __force_inline. I do think, from an optimization point of view, that it is /not/ an optimal/complete solution. It would often be better to request at a call-site that the function should be inline here, and only here. -Thorsten
On 10/10/2011 10:47, Thorsten Ottosen wrote:
I do think, from an optimization point of view, that it is /not/ an optimal/complete solution. It would often be better to request at a call-site that the function should be inline here, and only here.
Yes, that would be better, but AFAIK only GCC supports this (flatten attribute).
Thorsten Ottosen wrote:
I was trying to optimize some of our performance critical code. Step one is to find the bottlenecks with some tool. I used the one that comes with visual C++.
After running this, I had a great overview over which functions took up most of the time, and which functions that were called a lot (say, many million times). Usually, the compiler will not inline a large function because the saved time is neglible and more code is generated. However, the compiler can usually not know that a large function often returns quickly where large parts of the code of the function is only used sometimes.
Hence I used __force_inline.
Did you also try profile-driven optimisation? Regards, Phil.
Den 10-10-2011 11:54, Phil Endecott skrev:
Thorsten Ottosen wrote:
Hence I used __force_inline.
Did you also try profile-driven optimisation?
Yes, it gave a little extra, but not much. Also, for some projects, profile-driven optimization is simply not feasible. We evaluated it here at work, and it just didn't work out. Too many code paths that are hot in different circumstances, and the
On 10.10.2011 12:11, Thorsten Ottosen wrote: profile-enabled executable was just too slow. (We develop high-performance simulation software.) Sebastian
FYI: Such a macro already exists in boost/gil/gil_config.hpp as GIL_FORCEINLINE. It reduces to just "inline" for debug builds but apart from that does what you propose. Regards, Kai On 10/10/11, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
Den 10-10-2011 11:54, Phil Endecott skrev:
Thorsten Ottosen wrote:
Hence I used __force_inline.
Did you also try profile-driven optimisation?
Yes, it gave a little extra, but not much. Also, for some projects, profile-driven optimization is simply not feasible. We evaluated it here at work, and it just didn't work out. Too many code paths that are hot in different circumstances, and the
On 10.10.2011 12:11, Thorsten Ottosen wrote: profile-enabled executable was just too slow. (We develop high-performance simulation software.)
Sebastian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
El 10/10/2011 10:47, Thorsten Ottosen escribió:
After running this, I had a great overview over which functions took up most of the time, and which functions that were called a lot (say, many million times). Usually, the compiler will not inline a large function because the saved time is neglible and more code is generated. However, the compiler can usually not know that a large function often returns quickly where large parts of the code of the function is only used sometimes.
Sometimes is useful to split the function into two functions, one with the fast path and another with a call to a non-inlineable functions: void push_back(const T &t) //<- inlineable { if(m_capacity > m_size){ new (m_buffer+m_size) T(t); ++m_size; } else{ expand_and_insert_back(t); //<- non-inlineable big function } } Of course this does not guarantee push_back will be inlined... so I'd apply BOOST_FORCE_INLINE to push_back ;-)
El 09/10/2011 15:30, Mathias Gaunard escribió:
I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp
Who do I need to contact to make this happen?
Then let's add BOOST_NO_INLINE which is __declspec(noinline) in MSVC and __attribute__((noinline)) in GCC and compatible compilers. Ion
participants (16)
-
Andrew Hundt -
Beman Dawes -
Domagoj Saric -
Eric Niebler -
Ion Gaztañaga -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Kai Schroeder -
Mathias Gaunard -
Niels Dekker - address until 2014 -
Olaf van der Spek -
Phil Endecott -
Sebastian Redl -
Stewart, Robert -
Thorsten Ottosen -
Vicente J. Botet Escriba