Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77077 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8236 invoked from network); 5 Sep 2014 17:40:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Sep 2014 17:40:24 -0000 Authentication-Results: pb1.pair.com header.from=php_lists@realplain.com; sender-id=softfail Authentication-Results: pb1.pair.com smtp.mail=php_lists@realplain.com; spf=softfail; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain realplain.com does not designate 216.33.127.80 as permitted sender) X-PHP-List-Original-Sender: php_lists@realplain.com X-Host-Fingerprint: 216.33.127.80 mta11.charter.net Solaris 10 1203 Received: from [216.33.127.80] ([216.33.127.80:59596] helo=mta11.charter.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/05-12208-885F9045 for ; Fri, 05 Sep 2014 13:40:24 -0400 Received: from imp11 ([10.20.200.11]) by mta11.charter.net (InterMail vM.8.01.05.09 201-2260-151-124-20120717) with ESMTP id <20140905174020.NMXH4658.mta11.charter.net@imp11>; Fri, 5 Sep 2014 13:40:20 -0400 Received: from mtaout004.msg.strl.va.charter.net ([68.114.190.29]) by imp11 with smtp.charter.net id nVgL1o00D0eWGlw05VgLKc; Fri, 05 Sep 2014 13:40:20 -0400 Received: from impout005 ([68.114.189.20]) by mtaout004.msg.strl.va.charter.net (InterMail vM.9.00.013.00 201-2473-140) with ESMTP id <20140905174020.SFTR13360.mtaout004.msg.strl.va.charter.net@impout005>; Fri, 5 Sep 2014 12:40:20 -0500 Received: from pc1 ([96.35.251.86]) by impout005 with charter.net id nVgL1o00G1sc0so01VgLfp; Fri, 05 Sep 2014 12:40:20 -0500 X-Authority-Analysis: v=2.1 cv=Jpl/raIC c=1 sm=1 tr=0 a=Is5gsZaFXO8aPum+t7Tz+g==:117 a=Is5gsZaFXO8aPum+t7Tz+g==:17 a=hOpmn2quAAAA:8 a=hrnPcQGoKqUA:10 a=3sBgxdPApI8A:10 a=WUgRJF_wMoEA:10 a=N659UExz7-8A:10 a=BCPeO_TGAAAA:8 a=NEAV23lmAAAA:8 a=67BIL_jfAAAA:8 a=lpzs8nt7sEx88RsCPkMA:9 a=pILNOxqGKmIA:10 Message-ID: <017CEF5564AC4DF388331B030EF11A91@pc1> To: "Anatol Belski" , "Stas Malyshev" Cc: , "Pierre Joye" References: <5404DBD1.8050604@sugarcrm.com> <209db784d40e796718975276b74725de.squirrel@webmail.klapt.com> Date: Fri, 5 Sep 2014 12:40:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [INTERNALS-WIN] [PATCH] Microsecond resolution and accuracy on Windows From: php_lists@realplain.com ("Matt Wilmas") 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