Mac/PC physics/timing difference

[Jonathan_NL]

I know, sqrt returns a double. I was actually confused because I didn't see things fit together. Have you already tried ((float)sqrt((double)somefloat))?

[woody]

Quote (Jonathan_NL @ Sep. 29 2004,11:42)

so there must be some difference in the physics or timing? http://www.pontifex2.com/iB_html/non-cgi/emoticons/rock.gif" border="0" valign="absmiddle" alt='???'>

Where do you see these differences?

[woody]

Quote (Chronic Logic - Alex @ Oct. 01 2004,8:44)

Actually the accuracies for the sqrt functions are the same, but the different compilers convert the double back to a float at different times.  The main problem is Visual C seems to ignore casting a double back to a float, even with optimizations off.  I'm not sure why the Linux and Mac versions are different yet.

If you did the final build on the PC using GCC I assume it would be the same. I also assume the final executable would be slower, so I guess that isn't a good plan!
Presumable linux and the Mac should be the same.

However in this case, My Mac and Jonathans Mac produce different results (I assume).

[Jonathan_NL]

Just try a PC replay on the Mac or a Mac replay on the PC. There is a PC replay included with Gish (also the Mac version). Mac replay: http://home.filternet.nl/~eo000199/jonathan/gish/Jonathan-C12.gre.gz" target="_blank">Jonathan-C12.gre.gz

[Jonathan_NL]

That has to do with the latest patch, it seems.

Edit: http://home.filternet.nl/~eo000199/jonathan/gish/Jonathan-C20.gre.gz" target="_blank">Made one with the new version.

[woody]

I think it is more than a mac-pc difference then as when I play that back on my mac you storm round the left, over the top, break the right hand side platforms and end up trapped at the right-middle until it times out.

Unless that is actually what happened I guess there is a processor timing issue in there somewhere!

[woody]

Well, that worked but then I would assume it is a less timing critical level.
Still a damn site better than I can do!!

[Chronic Logic - Alex]

The problem is a difference in accuracies for the square root function that is used in the physics.  Unfortunately its different for all 3 versions, which makes it difficult to fix.

[woody]

If all of the maths is done in floats rather than doubles, it might be worth using vsqrtf(vFloat val) instead of sqrt - it is a lot faster and thats where gish seems to spend most of its time.
It is part of the vector libraries (altivec processor unit).
For real performance increase it should be noted that if you can feed the altivec unit fast enough you can do >= 4 vsqrt()s simultaneously with no overhead on the processor.

[Jonathan_NL]

I already thought that it was something like this, at the root of the physics. ;-)

Have you ever done tests on how fast/accurate the different sqrt()s actually are?

[Jonathan_NL]

I quickly hacked vsqrtf in a for(i=0; i<10000000; i++) loop without much altivec knowledge (looked everything up). It is twice as fast as sqrt() in the same loop, and remember that it does 4 at a time!

Edit: My first successful asm is an altivec instruction. http://www.pontifex2.com/iB_html/non-cgi/emoticons/laugh.gif" border="0" valign="absmiddle" alt=':laugh:'> If you're interested btw:

Code Sample

vUInt32 in = (vUInt32)('siht', ' si ', 'brag', '!ega'); vUInt32 perm = (vUInt32)(0x03020100, 0x07060504, 0x0B0A0908, 0x0F0E0D0C); // the permute value for byte-swapping 4 32-bit values. note that you can get data from a second vector (unused in this case. it's the second %1 below, and can be reached with 0x1*) to put in the result. vUInt8 out; asm("vperm %0,%1,%1,%2":"=v"(out):"v"(in),"v"(perm)); // couldn't find this in the altivec c extensions? printf("%vc\n", out);

A vector is just 128 bits, so 4 floats can be simultaneously 16 chars, or actually nothing: just 128 bits.

Edit again: can't find vperm c extension? Search at the right place!

Code Sample

vUInt8 out = vec_perm((vUInt8)in,(vUInt8)in,(vUInt8)perm); // I'm forced to almost-cast because the compiler doesn't like it, even though it makes no difference!

I expected this name, but I couldn't find the function where I searched for it at first.

Edit agaaaain: Condensed version:

Code Sample

vUInt32 in = (vUInt32)('siht',' si ','brag','!ega'); printf("%vc\n",vec_perm((vUInt8)in,(vUInt8)in,(vUInt8)(vUInt32)(0x03020100,0x07060504,0x0B0A0908,0x0F0E0D0C)));

http://developer.apple.com/hardware/ve/" target="_blank">http://developer.apple.com/hardware/ve/ (ve=velocity engine)

[Chronic Logic - Alex]

Actually the accuracies for the sqrt functions are the same, but the different compilers convert the double back to a float at different times.  The main problem is Visual C seems to ignore casting a double back to a float, even with optimizations off.  I'm not sure why the Linux and Mac versions are different yet.

[Jonathan_NL]

Can you explain that a little more detailed?

[Chronic Logic - Alex]

The sqrt function returns a double, in Gish the physics all use floats, so the compiler should convert the double back to a float on the line that it is called.  For some reason the Visual C compiler doesn't convert it back to a float on the line that it should, so it does some other calculations in double accuracy instead of float.

[Jonathan_NL]

The replay format is the same:
int magic;
int level;
int length;
char actions[length];

so there must be some difference in the physics or timing? http://www.pontifex2.com/iB_html/non-cgi/emoticons/rock.gif" border="0" valign="absmiddle" alt='???'>