This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Performance testing function pointers


Scott Bronson wrote:
It appears that function pointers are usually exactly as fast
as direct function calls except that with -O1 they're a few
percentage points slower, and with -O3 (in this specific case)
they're 18-20% faster!

There are a number of things that are odd about your testcase.


Using volatile for a function return type doesn't really do anything useful. It used to in old gcc releases, but that feature was removed long ago I believe. -O3 turns on inlining, and if you look, you will see that the function is getting inlined. There is an attribute noinline which you can use to prevent a function from being inlined. This does work with gcc-3.3.x.

You declared the argument as "volatile int* volatile p". If all you want is to prevent the increment from being deleted, then you only need the first volatile. That means we can't optimize away the read or write to *p. However, the volatile means we can't optimized away any read or write to p itself, and this causes problems. It means we have to read the value of p multiple times. This factor may be causing some of your strange results, as it prevents the compiler from generating the code you were expected. If you want meaningful results, you should delete the second volatile. With the second volatile, and function inlining, we get strange looking code like this:
movl -20(%ebp), %eax
movl -20(%ebp), %edx
movl -20(%ebp), %eax
The redudant loads could not be optimized away because you made the p itself volatile.


I suspect these may be responsible for some of your strange results. I was not able to reproduce the same results you saw though. With -O3, the code got faster because of function inlining.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]