You are correct, operation ordering is important. Although I did make sure the order of operations in the ptx was the “same”, exactly what order they get placed in when compiled I could not be sure of without using a disassembler.
Quite an good exercise is to rearrange your commutative operations in n! ways and then compare the results.
For example: x+y-z*(a+c-d)

gives you: (partial list)
x-z(a+c-d)+y
y+x-z(-d+c+a)
etc

etc. It is also possible to calculate your estimated max/min error based on your precision and order of operations

Thanks for the compiler / config details - I’ll give that a try later tonight on some image processing code I’m busy with.

By the way I see your hobbies are listed as: Fighting and Road Racing - so I’ll make sure I approve your comments extra quickly from now on!

Thanks for the tips. By “turned down” I was meaning turn the FPU down to 32 bits to match the CUDA floats internally.

I have actually never used SSE(2) in MSVC or any other C compiler for that matter - I rather implement them in a pure asm module (dinosoar….) as then I know exactly whats going on and not what a compiler has decided for me.

My build rules are set with the -keep option already There is a lot of information in those files which otherwise is hard to obtain - lmem usage for example.

That said: I did not check the compiler re-ordering the FPU instructions…. op ordering often causes rounding / trunc errors. Thanks for the advice I’ll have a look at the code this evening.

By the way - you mentioned gcc - have you ever managed to get nvcc to use gcc as the foreign compiler on a Windows machine?

You can enable SSE2 code generation in both cl (MSVC) and gcc and get it so that the old 80bit x86 float stack isn’t used (guessing this is what you ment by “turned down”). In fact if you are on (and compiling for) a 64-bit OS likely this is on by default. Also be careful with MSVC. Simply setting SSE on but not SSE2 on will result in the compiler still using the 80bit x86 float stack because SSE 32bit float wasn’t faster on early SSE1 only hardware. If I remember right, it will actually mix 80bit and SSE 32bit float operations in some cases.

BTW you might also want to set nvcc to keep intermediate output files. In one of those intermediate files you can actually see the functions used to emulate the GPU (seems like all the CUDA emulation stuff gets tossed into one file). Other things you might want to check out are issues with the compiler re-ordering FPU operations and issues with fused multiply+add vs x86 being separate. For MSVC might want to look at the /fp: options…