Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt

Hi Dmitry,

(cc'ing Johannes & Lukas)

> It looks like I missed this patch.
> What is the reason for it?

It was in context of PHP's round() behaviour, I also discovered
discrepancies of general FP behaviour between platforms.

Basically, on x86 systems without SSE FP arithmetics don't really use
IEEE 754 double arithmetic by default but rather a double-extended type
for internal calculations - which leads to problems since FP behaviour
is not reproducible on different platforms - compare to for example x86
with SSE or x86_64 where SSE is nearly always used, or PPC etc. - there
you get real IEEE 754 double arithmetic. The makes sure PHP changes the
internal FPU precision of x86 to IEEE 754 double precision in order to
get the same results for FP calculations on all platforms.

See:
http://wiki.php.net/rfc/rounding
http://www.christian-seiler.de/projekte/fpmath/

> It makes ~5% slowdown on Zend/bench.php Linux 32-bit.  :( 

Huh.. Strange. When I presented the patch (nobody except Lukas, Johannes
& Scott were interested anyway at that time) I knew there would be a
small performance penalty for the engine, but 5%? That is much higher
than I expected - which was definitely less than 1% (although I didn't
measure anything). What does zend/bench.php do? An unusual high amount
of FP arithmetics?

Currently, the patch saves the current FPU state, changes it to IEEE 754
double arithemtic, does the calculation and then restores the previous
state. This I did in order not to clash with other libraries that may be
loaded.

What we could do, however, would be to simply store the state in PHP on
a pre-request basis (i.e. use RINIT / RSHUTDOWN to store/change/restore
the state) and hope that no other library changes the state again (or,
if it does, wrap the invocation of that library). That would remove the
fnstcw/fldcw assembly instructions from around every FP operation -
which is probably the reason for the slowdown.

If you want to, I'll write a patch for that for PHP_5_3 and HEAD this
evening that may be discussed.

Regards,
Christian