Steven Watanabe wrote:
The problem is that the compiler (in some cases) generates case-based code when 'order' parameter is constant for caller: store( &myAtomic, 10, memory_order_relaxed) ; in this case instead of ONE assembler store instruction the compiler may generate many branch instruction. It is not optimal :-(. And 99% of code with atomic primitives has *constant* memory_order parameter.
Have you actually observed this? On which compilers?
Sorry, my previous post is incorrect. The problem has been observed on MS VC++ 2008 x86 build with full optimization. GCC 4.3.3 is my compiler for Unix systems. I did not study the problem on GCC. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Monday, March 29, 2010 6:49 PM To: boost@lists.boost.org Subject: Re: [boost] [lock-free] CDS -yet another lock-free library AMDG Khiszinsky, Maxim wrote:
2. Function-based implementation of atomics produces non-optimal code in some cases. Consider the usual implementation of atomic with explicit memory ordering: Static inline void store( atomic_t * pDest, atomic_t nVal, memory_order order ) { switch ( order ) { case memory_order_relaxed: *pDest = nVal; break ; case ... case ... } } The problem is that the compiler (in some cases) generates case-based code when 'order' parameter is constant for caller: store( &myAtomic, 10, memory_order_relaxed) ; in this case instead of ONE assembler store instruction the compiler may generate many branch instruction. It is not optimal :-(. And 99% of code with atomic primitives has *constant* memory_order parameter.
Have you actually observed this? On which compilers? In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost