Hi Anatol, Stas,
----- Original Message -----
From: "Anatol Belski"
Sent: Tuesday, September 02, 2014
On Mon, September 1, 2014 22:49, Stas Malyshev wrote:
Hi!
It's much more optimized than what's there now, and slightly over the
old implementation. Not sure if I should give the saved patch link, or
the "live compare" (?) on Github, so I'll do both for now:
http://realplain.com/php/microtime_5_4.diff
https://github.com/matt-moo/php-src/compare/PHP-5.4.diff
Against 5.4 since that's what I quickly worked on so it's ready for the
next 5.4 release (Stas?). (Although I guess we're supposed to change
the oldest branch usually?)
Looking at the patch, it looks like unfortunately it changes a global
structure (_php_win32_core_globals) which breaks binary compatibility. I
think if you move the additional value to the end of the structure it
should be ok though, since other offsets should not change then.
AFAIR the patch with ABI break was at the time where 5.5 was alpha, so the
change was backported. Was not intentional to break ABI and just based on
the good user feedback, and good tested anyway. Still used and shows no
issue in the phpt and app unit tests.
OK before, so should be OK now, right? I just figured the Windows globals
were "special"/not important and could be changed after seeing that...
Is anyone/anything actually using _php_win32_core_globals besides the core?
Nothing interesting there...?
I'm also not sure how important it is how have it for 5.4. Does the
problem that this patch fixes exist only in older versions of Windows or
on
all versions? What are the actual effects of this problem - is it just
lower resolution of microtime or there can be something seriously wrong
with the whole result? If it's just lower resolution, I'd prefer this to
go into 5.5 as the change is pretty extensive. --
That's the lower resolution on systems preceding win8. The previous issue
was time_before > time_after which was caused by the same approach Matt
has now in the patch.
Hopefully fixed now!
Also I've developed pecl.php.net/hrtime since then which provides the
exact solution - a stopwatch for inteval measurements, no synchronized
timestamps. The microtime in the core delivers the real timestamp, not a
computed one. But well, with an accuracy which one could wish to be
better. Currently, something like this can never be true
$time0 = microtime(true);
time1 = microtime(true);
var_dump($time1 - $time0 < 0);
Of course it *can* be true, currently. IF the system time is set backwards!
Unlike time itself, computer clocks aren't monotonic.
For the practical case, i'm not sure if with the Matt's patch one will be
able to make an ebay bid in the right time (assumed it's expected to have
microsecond precision). However with a lower accuracy there might be an
issue, too. Phony buggy timestamp vs. worse accuracy. Please consider also
the other issues like hardware/software i mentioned in the other mail.
eBay bid?!? :-O You'd have bigger problems than timestamps with that. Like
waiting for Windows' timers, before the unknowns like network latency. :-)
Regards
Anatol
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
