I have done more detailed benchs,
I can tell for sure that D10 is faster than any other Delphi until now
(integer and classes).
If you switch from D6-7-2005 you will notice the difference without run a
profiler.
D5+FMM4+FastCode patches vs D10
1) bench of poker card that stress class instances, arrays, for etc.: ~+10%
D5 597,000 hands for second (490,000 D5 not patched)
D10 671,000 hands for second
D7-2005 are slow than D5 from 7-to-40%, so let's imagine D10 vs D7
2) bench of hashes containers using Boyet classes: ~+4%
D5 3578Msec
D10 3422Msec
D7 is 30% slow in this than D5
3) bench of AES class, 340Mbytes stream encrypt: ~+2%
Pascal AES based D5 19359
Gladman ASM AES D5 4437
Pascal AES based D10 19031
Gladman ASM AES D10 4343
Haven't benchmarked with D7, but IMHO score similar, all is about getmem,
arrays and logical operands
The ide finally is fast, reliable, I feel as the first time I have
installed D2 (help aside).
Let me tell: Delphi apparently is back!
Btw. I don't have checked floating point, I know that in newer delphi you
need do a define to avoid strict runtime check of FF and come back to
better speed, maybe it's enabled also in this D10?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Do you like?
Thanks :)
IIRC this is an option meaningful for D.Net only.
Eric
Yes. In Win32 you can turn off floating point exceptions to get the same
runtime semantics, but it doesn't affect the performance there (except when
you have exceptions) as it does in .NET.
From my Delphi Language appendix of Jon Shemitz' upcoming book ".NET for
Delphi programmers":
http://www.amazon.com/gp/product/1590593863/102-4223013-3682543?v=glance&n=283155
"Floating-point semantics
Native Delphi signals invalid floating-point operations by raising
exceptions such as EZeroDivide and EOverflow. These semantics are preserved
in Delphi for .NET by default. While the Win32 floating-point exception
support is efficiently implemented directly in the processor hardware, the
corresponding .NET support must be implemented explicitly in software by
emitting the ckfinite IL instruction.
The .NET solution is a little slower, so if you have time-critical code that
do not depend on exceptions being raised, you can speed it up a little by
using the {$FINITEFLOAT OFF} compiler directive. In this mode, invalid
operations will return special floating-point values like NaN (Not a
Number), +Inf and -Inf (Infinity) instead of raising exceptions. To get the
same semantics in Win32 code, you use the SetExceptionMask function from the
Math unit.
{$IFDEF CLR}
{$FINITEFLOAT OFF}
{$ELSE}
Math.SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,
exOverflow, exUnderflow, exPrecision]);
{$ENDIF}
One := 0;
Two := 42;
Three := Two / One; // Returns +Inf, no exception raised
In .NET the generated IL code for the division statement is:
FloatingPointSemanticsU.pas.51: Three := Two / One;
IL_0063: ldloc.1
IL_0064: ldloc.0
IL_0065: div
IL_0066: ckfinite
IL_0067: stloc.2
At run time the ckfinite IL instruction actually expands into seven x86
instructions, including CALLing a routine - doing this for every
floating-point operation slows things down noticeably.
Tip Unless you absolutely need floating-point exceptions, turn them off with
{$FINITEFLOAT OFF}"