 |
lua-l archive |
|
|
||
|
If it 'only' means the FPU computes things differently internally, why does Lua start crashing as soon as DX sets this flag to single-precision? :-)I don't know why it crashes, and I don't want to start guessing here..
I ment it as a rhetorical question. ;) It crashes because it fails at least on the number2int conversion trick (see first link below). The issue has been discussed in this mailing list before:
http://lua-users.org/lists/lua-l/2005-10/msg00254.html http://lua-users.org/lists/lua-l/2005-11/msg00044.html http://lua-users.org/lists/lua-l/2005-10/msg00265.html http://lua-users.org/lists/lua-l/2006-03/msg00320.html
Don't forget that this 3.5% gain was measured in an ill formed test case. In real apps I doubt that you would see this much difference. Anyways,
I'm not saying that one test Google produced gives us the 3.5% as scientifically correct, well-researched proof at all. It simply is yet another indication DX can get slower when the FPU is in double-precision as stated in the documentation that comes with the DX SDK.
In real game apps, a possible 3.5% performance hit which can easily be avoided I would say definitely is worth the trouble. Not making the easy fix optimizing for 'only' 3.5% at least in our team would raise an eyebrowe or two. ;) (who knows, maybe it is 5%... or maybe 2%... maybe it depends on the driver, another piece of software we don't control...)
this is your call, if there's an easy fix, then good for you, but I would rather opt to just avoid all the trouble altogether. You never know when it's gonna pop up again in some form of mysterious bug...
The easy fix / avoiding the trouble altogether would of course be to define Lua to use float in stead of double. ;-)
Cheers,Hugo