Maybe a bug in VC++

[Serge K]

Originally posted by LordKronos:
Nope, when I tried to compile his fabs function, VC++ complained to me about not returning a value and refused to compile it.

Nonsense.
With #pragma warning(disable: 4035) you should not have any warnings about these functions.

BUT if you're using <math.h>, you have to rename cos, sin, fabs, ... to something different.

Originally posted by LordKronos:
maybe there is some keyword that you need to use to indicate the function returns it's value on the FPU stack

No. It is the standard calling convention for x86.

[LordKronos]

Originally posted by Serge K:
Nonsense.
With #pragma warning(disable: 4035) you should not have any warnings about these functions.

OK, my mistake. It generated a warning, not an error, so it can compile (maybe I had another error in my code that I confused with it, or maybe I was just being dumb).

OK, quick test using VC++ compiling with full optimizations. Called fabs in a loop 1,000,000,000 times. As it turns out, the library version of fabs is about 5 times faster than Humus' version of fabs. However, using the debug build, Humus' version is about 40% faster than the VC++ library version of fabs, so thats probably why he thought it was faster.

Guess this just helps to reinforce the idea that you should NEVER try to optimize your code based on the timings taken in the debug build. I remember one time long ago when I spent about 2 hours optimizing some code. It seemed that my optimizations had made the code about 3 times faster. Then when I switched to release build, my optimized release build was the exact same speed as the unoptimized release build. You can bet I havent made that mistake since then.

Somehow, this discussion got way off topic :-)

[Michael Steinberg]

I'd like to see that library function...

[Michael Steinberg]

Okay, I did a little benchmark with my own inline assembler fabs function.
In the worst case scenario (a rand for the float, so the compiler can't optimize too much for the fabs function) mine takes 46 seconds for a great number (it's too great than I could remember) whereas fabs takes 38 seconds. (The code to bench is exactly the same for both I believe).
If anybody could tell me how to only get a single byte from the float into a register that could optimize it a bit more, I guess.

[Humus]

Forgot __inline ... those speed up considerably. I haven't benchmarked it much but with __inline I get essentially the same speed as the release libs, except for fabs which was much slower (compiler perhaps just does a AND with 0x7FFFFFFF). The reason there's no speed improvement is because the FPU will still internally work with doubles, just as the lib functions. So, you should set the FPU to float precision and then use those functions. Then you'll see speed improvements. For inline assembler to really pay off you should however use longer functions than those since the function calling overhead may destroy all performance gains.

[Michael Steinberg]

Hey, I'm actually also only doing that and masking out the sign bit. But mine is as said a bit slower than the compiler. (it is inline).

[Humus]

I wonder how far a compiler optimizes a __inline call. Does anyone know if it still pushes the arguments on the stack or does it store them in registers?