Author: Walter Faxon
Date: 20:08:36 08/21/03
Go up one level in this thread
On August 21, 2003 at 18:22:32, Omid David Tabibi wrote:
>I changed some data structures in my program and added two functions (the
>variables are renamed below):
>
>void func1(unsigned int &a, int b, int c) {
> a += array[b][c];
>}
>
>BOOL func2(unsigned int a, int b, int c) {
> return (a & mask[b][c]);
>}
>
>These two functions are very heavily used all over the program. In MSVC 6 I use
>the "inline any suitable" option for inlining, so I assumed that the compiler
>would definitely inline these functions. But again, "assumption is the mother of
>all f**k-ups", after turning the warning level to 4, I found out that these
>functions were not chosen for inlining... strange for itself.
>
>So I added a __forceinline to each of them and recompiled. But still the speedup
>was negligible. So instead I wrote the following two macros:
>
>#define func1(a,b,c) (a += array[b][c])
>#define func2(a,b,c) ((a) & mask[b][c])
>
>Wao! about 20% speedup! I was certain that the two functions were not inlined
>previously when I added __forceinline. So I checked it again in warning level of
>4, but didn't find any warning indicating that they were not inlined (if you
>mention __inline or __forceinline, and the compiler can't inline, a warning is
>typically displayed).
Hi, Omid.
Most compilers have some option to list their generated output in assembler so
you can double-check what they do.
I wonder if my old bit scanning code didn't do so well by some reports because
"inline" doesn't always mean "inline".
I guess it depends on what the meaning of "is" is... ;)
-- Walter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.