Just a notice: I’ve updated the XE2 single-precision floating point article after using the (up to now) undocumented {$EXCESSPRECISION OFF} directive, thanks to Allen Bauer for chiming in!
Executive summary: this directives enables use of single-precision SSE floating point instruction by the compiler, and brings their performance in line with expectations, making Delphi XE2 64bit compiler the new King of the Delphi Hill.
Edit: now documented here: Floating point precision control (Delphi for x64). That was fast!
Edit 2: an issue in the compiler was found related to non-explicitly typed constants by Ville Krumlinde, see QC #98753, so be aware of potential incorrect code generation with the initial version of the 64 bits compiler.
Edit 3: if you happen to be one of the error insight users, it will complain that the directive doesn’t exist.
Edit 4: the compiler issue was fixed for Delphi XE2 Update1!
Let’s hope that this directive will be fully supported, and in time face the same fate as $STRINGCHECKS did (ie. become another scary story for the long winter nights).
Has an article now. You can link it in your blog post: http://docwiki.embarcadero.com/RADStudio/en/Floating_point_precision_control_%28Delphi_for_x64%29
Found a minor problem with the new directive and reported it here: http://qc.embarcadero.com/wc/qcmain.aspx?d=98753
ISTM that both MS VC++ and Intel C++ uses /fp:precise by default, so I guess there will be some opposition if we want this to change.
Thank you!
@Mattias Andersson
Probably, but that would be logical to drop it, just like you don’t expect your 32bits integer arithmetic to be performed in 64bit, and the actual precision gains from such hidden tricks are very circumstantial, and make the code fragile.
For instance, refactoring a lengthy unpalatable expression into N simpler expressions means you’ll lose precision if you were relying on hidden excess precision.
Eric, I agree 100% — I did write about the performance issues that you also reported about as early as in May this year. Of course I was very happy to learn about {$EXCESSPRECISION OFF} (which was reported by one of the compiler engineers when I brought this subject up once again.)
One of the main arguments seems to be that in 32-bit, all floating point operations are automatically promoted to 80bit extended precision and they want 64-bit to be as close to this as possible. Also, when I’m checking the Microsoft and Intel pages they’re referring to the ANSI standard.
@Mattias Andersson
The key article on the subject seems to be http://msdn.microsoft.com/en-us/library/Aa289157, though as far as I can tell, it’s only pertinent when intermediate assignments end up in registers, and not in memory. It sounds like yet another case of trying to hide a problem under the carpet.
Neither fp:precise nor fp:fast seem to be completely clean, the first always promotes if possible, the second may perform at a lower precision than specified, so the middle-ground appears to be missing: compile at the precision you’re told to compile, and don’t try to be smarter than your master 😉
@Ville: Thanks for the report. I’ve promoted it.
And let’s hope that the SCOPEDENUMS directive follows it into oblivion where it belongs.
(I firmly believe that whoever came up with “SCOPEDENUMS” was actually thing more along the lines of “FORCEENUMSTOLOOKLIKECLASSCONSTANTSTOKEEPTHEDOTNETANDJAVABRIGADEHAPPY”)
thing more == thinking more… doh!