Re: [INTERNALS-WIN] [PATCH] Microsecond resolution and accuracy on Windows

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