Hi, > For the record, I was very excited to see your proposal and the work you've > done.
Thanks! :) > I'm not a PHP dev so I can't comment on the patch, maybe there might > be a performance concern? The new algorithm is slightly slower in most of the cases and quite a bit slower if strings have to be used in order to ensure correctness. The following table shows the performance comparison of the algorithm when compiling 5.3 with gcc 4.1.2 on Gentoo Linux with and without optimization activated: +----+----+-----------------------+-----------------------+ | | | without patch | with patch | | st | pr | -O0 -ggdb | -O2 | -O0 -ggdb | -O2 | +----+----+-----------+-----------+-----------+-----------+ | - | X | 6.427930 | 3.151313 | 7.107897 | 3.581429 | | X | X | 6.485305 | 3.197008 | 26.423409 | 15.571503 | | X | - | 6.318853 | 3.124304 | 11.926427 | 6.910457 | | - | - | 6.100793 | 2.850991 | 6.636300 | 2.926919 | | precov. | 5.432411 | 2.382959 | 5.524717 | 2.382117 | +----+----+-----------+-----------+-----------+-----------+ Times are in seconds, script was basically the following: $start = microtime(true); for ($i = 0; $i < 5000000; $i++) $ret = round (/*number*/, /*prec*/); $end = microtime(true); printf("%.6f\n", $end - $start); Explanations for the left columns: st: Uses to-string-and-back conversion to ensure correctness (the case when |places| > 22) pr: Uses prerounding to precision to ensure correctness (see RFC for details) precov: Precision overflow, i.e. rounding 12345.123456789012345 to more than 10 places precision (which is the max. that doubles can represent) The most commen case by far would be the first one (things such as round(12.245, 2)), the cases where string-conversion is used are probably extremely rare (remember, |second parameter of round| must be > 22). I used the following numbers to test the combinations: -st +pr: round (0.116, 2) +st +pr: round (0.000000000000000000000000000000116, 32) +st -pr: round (0.000000000000000000000000000000005, 30) -st -pr: round (0.005, 0) precov.: round (1, 30) As you can see, the cases which don't to string-and-back conversion are not problematic: There's basically no difference for the precision overflow case, the case with prerounding is slightly slower and the case without prerounding is actually slightly faster when compiler optimizations are enabled (this is due to the fact that the 10^places was optimized in my patch). So the most common cases basically don't matter much at all. The only potential problems are the cases where the second parameter of the round() function is larger than 22 or smaller than -22. In that case, the new algorithm is quite a bit slower than the old one (nearly factor 5 for all numbers that won't become 0 after rounding). But these are edge cases which won't happen that often and if people actually have these numbers they are probably far more interested in correctness than in performance [see for example var_dump(2e-23 - round(2e-23,23));]. ---------------------------- snip ---------------------------------- @internals: Anyway, since nobody of the core devs seems to be interested in this topic, is there any objection to me committing this patch to HEAD? @Johannes, @Lukas: Should there be a decision for an alpha3 release of PHP 5.3 due to the namespace discussion, is there any objection to me committing this patch to PHP_5_3? Should there be directly a beta1 release, any objections against this patch in 5.3.1? Or, even though it is a rewrite of the round() function, may this even qualify as a bugfix, since the previous behaviour was erroneous (see for example <http://bugs.php.net/bug.php?id=42294> and my RFC)? Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php