Re: [INTERNALS-WIN] [PATCH] Microsecond resolution and accuracy on Windows
| From: | Matt Wilmas | Date: | Fri, 05 Sep 2014 17:40:20 +0000 |
| Subject: | Re: [INTERNALS-WIN] [PATCH] Microsecond resolution and accuracy on Windows | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77077@lists.php.net to get a copy of this message | ||
Hi Anatol, Stas,
----- Original Message -----
From: "Anatol Belski"
Sent: Tuesday, September 02, 2014
On Mon, September 1, 2014 22:49, Stas Malyshev wrote: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...?Hi!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.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.
Hopefully fixed now!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.
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