Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] High resolution timer function

Posted by Anatol Belski 
Anatol Belski
[PHP-DEV] High resolution timer function
December 16, 2017 03:10PM
Hi,

I would like to propose a function for high resolution monotonic timing. There was discussions about this before and a PR https://github.com/php/php-src/pull/2368 which has issues and was abandoned. I've filed https://github.com/php/php-src/pull/2976 with some reworked implementation.

A monotonic timer can be usable in several situations besides benchmarking. Having a simple functionality like this in the core should be a useful addition. The current approach is a function returning array of [seconds, nanoseconds] and optionally returning full nanosecond number as int on 64-bit or float on 32-bit. The first way is the most portable. Quite a few platforms are already supported by the current implementation.

IMHO it should be fine to have a function like this in the core, perhaps also a few helper functions could be useful, too. I would like to pursue 7.3 with this. Please lets check for any concerns in general or with implementation, naming, etc.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anatol Belski
[PHP-DEV] RE: High resolution timer function
January 02, 2018 11:50AM
Hi,

> -----Original Message-----
> From: Anatol Belski [mailto:[email protected]] On Behalf Of Anatol Belski
> Sent: Saturday, December 16, 2017 3:03 PM
> To: internals@lists.php.net
> Cc: Niklas Keller <[email protected]>
> Subject: [PHP-DEV] High resolution timer function
>
> Hi,
>
> I would like to propose a function for high resolution monotonic timing. There
> was discussions about this before and a PR https://github.com/php/php-
> src/pull/2368 which has issues and was abandoned. I've filed
> https://github.com/php/php-src/pull/2976 with some reworked
> implementation.
>
> A monotonic timer can be usable in several situations besides benchmarking.
> Having a simple functionality like this in the core should be a useful addition. The
> current approach is a function returning array of [seconds, nanoseconds] and
> optionally returning full nanosecond number as int on 64-bit or float on 32-bit.
> The first way is the most portable. Quite a few platforms are already supported
> by the current implementation.
>
> IMHO it should be fine to have a function like this in the core, perhaps also a few
> helper functions could be useful, too. I would like to pursue 7.3 with this. Please
> lets check for any concerns in general or with implementation, naming, etc.
>
If there are no further comments or objection, I would like to merge this patch anytime soon and see to add a couple of helper functions for diff/compare.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Peter Cowburn
Re: [PHP-DEV] RE: High resolution timer function
January 02, 2018 03:00PM
On 2 January 2018 at 10:43, Anatol Belski <[email protected]> wrote:

> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [mailto:[email protected]] On Behalf Of Anatol
> Belski
> > Sent: Saturday, December 16, 2017 3:03 PM
> > To: internals@lists.php.net
> > Cc: Niklas Keller <[email protected]>
> > Subject: [PHP-DEV] High resolution timer function
> >
> > Hi,
> >
> > I would like to propose a function for high resolution monotonic timing.
> There
> > was discussions about this before and a PR https://github.com/php/php-
> > src/pull/2368 which has issues and was abandoned. I've filed
> > https://github.com/php/php-src/pull/2976 with some reworked
> > implementation.
> >
> > A monotonic timer can be usable in several situations besides
> benchmarking.
> > Having a simple functionality like this in the core should be a useful
> addition. The
> > current approach is a function returning array of [seconds, nanoseconds]
> and
> > optionally returning full nanosecond number as int on 64-bit or float on
> 32-bit.
> > The first way is the most portable. Quite a few platforms are already
> supported
> > by the current implementation.
> >
> > IMHO it should be fine to have a function like this in the core, perhaps
> also a few
> > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
> > lets check for any concerns in general or with implementation, naming,
> etc.
> >
> If there are no further comments or objection, I would like to merge this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
>
>
Why is this bypassing the RFC process?


> Regards
>
> Anatol
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Anatol Belski
RE: [PHP-DEV] RE: High resolution timer function
January 02, 2018 05:00PM
Hi,

> -----Original Message-----
> From: Peter Cowburn [mailto:[email protected]]
> Sent: Tuesday, January 2, 2018 2:56 PM
> To: Anatol Belski <[email protected]>
> Cc: internals@lists.php.net; Niklas Keller <[email protected]>
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
>
>
> On 2 January 2018 at 10:43, Anatol Belski <[email protected] <mailto:[email protected]> >
> wrote:
>
>
> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [mailto:[email protected]
> <mailto:[email protected]> ] On Behalf Of Anatol Belski
> > Sent: Saturday, December 16, 2017 3:03 PM
> > To: internals@lists.php.net <mailto:[email protected]>
> > Cc: Niklas Keller <[email protected] <mailto:[email protected]> >
> > Subject: [PHP-DEV] High resolution timer function
> >
> > Hi,
> >
> > I would like to propose a function for high resolution monotonic
> timing. There
> > was discussions about this before and a PR
> https://github.com/php/php-
> > src/pull/2368 which has issues and was abandoned. I've filed
> > https://github.com/php/php-src/pull/2976
> https://github.com/php/php-src/pull/2976 with some reworked
> > implementation.
> >
> > A monotonic timer can be usable in several situations besides
> benchmarking.
> > Having a simple functionality like this in the core should be a useful
> addition. The
> > current approach is a function returning array of [seconds,
> nanoseconds] and
> > optionally returning full nanosecond number as int on 64-bit or float
> on 32-bit.
> > The first way is the most portable. Quite a few platforms are already
> supported
> > by the current implementation.
> >
> > IMHO it should be fine to have a function like this in the core, perhaps
> also a few
> > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
> > lets check for any concerns in general or with implementation,
> naming, etc.
> >
> If there are no further comments or objection, I would like to merge this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
>
>
>
>
> Why is this bypassing the RFC process?
>
The functionality is obvious and won't cause any BC issues. It was requested several times in the past, the patch was around for quite some time in several versions. Smaller pieces don't always require RFC. If there's no consent on ML, the RFC is required. That's where I stood, at least. The spared effort can be invested in some other areas. Is there some concrete concern on your side, about the implementation, etc.? I'd be glad to hear any feedback, can go for RFC, too.

Regards

Anatol
Stanislav Malyshev
Re: [PHP-DEV] RE: High resolution timer function
January 02, 2018 08:50PM
Hi!

> If there are no further comments or objection, I would like to merge this patch anytime soon and see to add a couple of helper functions for diff/compare.

No objection to the idea but please see my comments on
https://github.com/php/php-src/pull/2976.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anatol Belski
RE: [PHP-DEV] RE: High resolution timer function
January 03, 2018 12:00AM
> -----Original Message-----
> From: Stanislav Malyshev [mailto:[email protected]]
> Sent: Tuesday, January 2, 2018 8:43 PM
> To: Anatol Belski <[email protected]>; internals@lists.php.net
> Cc: Niklas Keller <[email protected]>
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
> Hi!
>
> > If there are no further comments or objection, I would like to merge this patch
> anytime soon and see to add a couple of helper functions for diff/compare.
>
> No objection to the idea but please see my comments on
> https://github.com/php/php-src/pull/2976.
>
Thanks, Stas. I'm working to address your comments now.

Regards

Anatol
Dan Ackroyd
Re: [PHP-DEV] RE: High resolution timer function
January 05, 2018 11:40AM
On 2 January 2018 at 13:55, Peter Cowburn <[email protected]> wrote:
>
>
> Why is this bypassing the RFC process?

That's a very good question.

Although I'm pretty sure an RFC for this would pass unanimously, stuff
should have to go through voting rather than relying on no-one
shouting loudly enough.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] RE: High resolution timer function
January 05, 2018 12:50PM
On 5 January 2018 at 10:38, Dan Ackroyd <[email protected]> wrote:

> On 2 January 2018 at 13:55, Peter Cowburn <[email protected]> wrote:
> >
> >
> > Why is this bypassing the RFC process?
>
> That's a very good question.
>
> Although I'm pretty sure an RFC for this would pass unanimously, stuff
> should have to go through voting rather than relying on no-one
> shouting loudly enough.
>


Just as a counter-point to this, I understand that many (Westminster
style?) parliaments have mechanisms to skip uncontroversial votes by first
requiring a show of hands or voices, and only "dividing the house" (making
everyone get up and register their formal votes) if there is dissent.

I think Anatol's intent here is similar: if anyone says "Nay", we can
proceed with an RFC and vote; but if it's already unanimous, why spend the
time, when we could be moving onto other business?

Regards,
--
Rowan Collins
[IMSoP]
Rasmus Lerdorf
Re: [PHP-DEV] RE: High resolution timer function
January 05, 2018 05:50PM
Definitely. Small, uncontroversial changes have never required an RFC.
Let's not add process just for the sake of process.

-Rasmus

On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins <[email protected]>
wrote:

> On 5 January 2018 at 10:38, Dan Ackroyd <[email protected]> wrote:
>
> > On 2 January 2018 at 13:55, Peter Cowburn <[email protected]>
> wrote:
> > >
> > >
> > > Why is this bypassing the RFC process?
> >
> > That's a very good question.
> >
> > Although I'm pretty sure an RFC for this would pass unanimously, stuff
> > should have to go through voting rather than relying on no-one
> > shouting loudly enough.
> >
>
>
> Just as a counter-point to this, I understand that many (Westminster
> style?) parliaments have mechanisms to skip uncontroversial votes by first
> requiring a show of hands or voices, and only "dividing the house" (making
> everyone get up and register their formal votes) if there is dissent.
>
> I think Anatol's intent here is similar: if anyone says "Nay", we can
> proceed with an RFC and vote; but if it's already unanimous, why spend the
> time, when we could be moving onto other business?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
Anatol Belski
RE: [PHP-DEV] RE: High resolution timer function
January 06, 2018 12:40AM
Hi Rasmus,

> -----Original Message-----
> From: Rasmus Lerdorf [mailto:[email protected]]
> Sent: Friday, January 5, 2018 5:42 PM
> To: Rowan Collins <[email protected]>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
> Definitely. Small, uncontroversial changes have never required an RFC.
> Let's not add process just for the sake of process.
>
That was my premise, too, similar to what Rowan's second mail expressed. I myself didn't think it would be something big to vote, just to make lists aware. The PHP interface might be a subject to nitpick, but otherwise it's a long requested feature. I'm still to the QA of the patch, the PHP interface is still choosable of course, the functionality itself is to the big part ready.

Thanks.

Anatol


> -Rasmus
>
> On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins <[email protected]>
> wrote:
>
> > On 5 January 2018 at 10:38, Dan Ackroyd <[email protected]> wrote:
> >
> > > On 2 January 2018 at 13:55, Peter Cowburn <[email protected]>
> > wrote:
> > > >
> > > >
> > > > Why is this bypassing the RFC process?
> > >
> > > That's a very good question.
> > >
> > > Although I'm pretty sure an RFC for this would pass unanimously, stuff
> > > should have to go through voting rather than relying on no-one
> > > shouting loudly enough.
> > >
> >
> >
> > Just as a counter-point to this, I understand that many (Westminster
> > style?) parliaments have mechanisms to skip uncontroversial votes by first
> > requiring a show of hands or voices, and only "dividing the house" (making
> > everyone get up and register their formal votes) if there is dissent.
> >
> > I think Anatol's intent here is similar: if anyone says "Nay", we can
> > proceed with an RFC and vote; but if it's already unanimous, why spend the
> > time, when we could be moving onto other business?
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
Anatol Belski
RE: [PHP-DEV] RE: High resolution timer function
January 08, 2018 05:50PM
Hi,

> -----Original Message-----
> From: Anatol Belski [mailto:[email protected]] On Behalf Of Anatol Belski
> Sent: Saturday, January 6, 2018 12:31 AM
> To: Rasmus Lerdorf <[email protected]>; Rowan Collins
> <[email protected]>
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] RE: High resolution timer function
>
> Hi Rasmus,
>
> > -----Original Message-----
> > From: Rasmus Lerdorf [mailto:[email protected]]
> > Sent: Friday, January 5, 2018 5:42 PM
> > To: Rowan Collins <[email protected]>
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] RE: High resolution timer function
> >
> > Definitely. Small, uncontroversial changes have never required an RFC.
> > Let's not add process just for the sake of process.
> >
> That was my premise, too, similar to what Rowan's second mail expressed. I
> myself didn't think it would be something big to vote, just to make lists aware.
> The PHP interface might be a subject to nitpick, but otherwise it's a long
> requested feature. I'm still to the QA of the patch, the PHP interface is still
> choosable of course, the functionality itself is to the big part ready.
>
This patch was merged a short while ago. Since then, a concern was raised on the PR page https://github.com/php/php-src/pull/2976#issuecomment-355882740 , that providing a high resolution timer could have impacts to shared hostings with regard to the Spectre vulnerability. The paper https://spectreattack.com/spectre.pdf describes a reproduce way in Javascript, which is why current browsers already issued a patch to reduce the timer resolutions as a part of mitigation. In further in the PR, it was suggested to provide a separate function that only cares about the monotony, but delivers time as milliseconds.

Now, as one can see in the paper, Javascript can provide an attack vector, because it compiles to JIT and because browsers provide certain features. Neither of those are currently available in PHP. Furthermore, PHP itself as any other program is vulnerable to Meltdown/Spectre and a proper fix is only available on the OS and hardware levels. Both features, high resolution and monotonic timer was requested earlier also not only those that led to this PR.

As it is now a few days after the disclosure, it is not quite clear how much impact high resolution timers might have on the PHP side in the future. At least, it doesn't seem obvious these issues are something to be fixed on the PHP side. For now, my suggestion were to keep hrtime() in the core and to implement monotonictime() that provides millisecond resolution. I'm working on that right now. If later on it turns out, that high resolution timers are a general security impact, parts regarding gettimeofday and microtime would have to be touched, too. But the monotonic low resolution timer would still have no impact, at least by today's knowledge. The Meltdown/Spectre issue is definitely something, that needs to be monitored with the regard to impacts to PHP.

Regards

Anatol

>
>
> > -Rasmus
> >
> > On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins
> > <[email protected]>
> > wrote:
> >
> > > On 5 January 2018 at 10:38, Dan Ackroyd <[email protected]> wrote:
> > >
> > > > On 2 January 2018 at 13:55, Peter Cowburn <[email protected]>
> > > wrote:
> > > > >
> > > > >
> > > > > Why is this bypassing the RFC process?
> > > >
> > > > That's a very good question.
> > > >
> > > > Although I'm pretty sure an RFC for this would pass unanimously,
> > > > stuff should have to go through voting rather than relying on
> > > > no-one shouting loudly enough.
> > > >
> > >
> > >
> > > Just as a counter-point to this, I understand that many (Westminster
> > > style?) parliaments have mechanisms to skip uncontroversial votes by
> > > first requiring a show of hands or voices, and only "dividing the
> > > house" (making everyone get up and register their formal votes) if there is
> dissent.
> > >
> > > I think Anatol's intent here is similar: if anyone says "Nay", we
> > > can proceed with an RFC and vote; but if it's already unanimous, why
> > > spend the time, when we could be moving onto other business?
> > >
> > > Regards,
> > > --
> > > Rowan Collins
> > > [IMSoP]
> > >
Sorry, only registered users may post in this forum.

Click here to login