Re: Comment on High Resolution Time Last Call Draft

I understand, and I certainly don't plan to push this if the general 
feeling of those doing the implementations is that it's impractical. One of 
the reasons I suggested a SHOULD is that it at least increases the chances 
that the now() function would be useful for fine grained timing on 
platforms where that is easily implementable, without requiring it when 
it's hard. Of course, if it's only a SHOULD, you can't count on it for a 
unique identifier, and need something like a short library routine to 
enforce uniqueness when necessary.

I guess what I'm saying is: if there were at least some way to advise 
implementors that taking the trouble to provide a fine-grain time may have 
some value, I'd be in favor. I can understand why you don't feel it should 
be required.


 > high resolution profiling can be done using developer tools, or by building
 > a benchmark that runs many iterations.

Sometimes. I've certainly built systems where having fine grained clock 
made things much easier.

In any case, thank you for considering my comment.

Noah

On 3/13/2012 3:03 PM, James Simonsen wrote:
> Hi Noah,
>
> I don't think that's something we'd want to spec. Browsers, unfortunately,
> are highly dependent on the underlying system they run on. We can't
> guarantee that every system an HTML5-compatible browser would run on will
> be able to provide sufficient resolution to time individual instructions.
>
> Stalling when the clock hasn't advanced would be a no-go. That's bad user
> experience.
>
> So, rather than setting such expectations in the spec, and letting web
> developers depend on it, we'd rather they just not make such assumptions in
> the first place.
>
> I think there could be other solutions for your use cases. For instance,
> there should probably be a proper way of getting a unique ID, rather than
> inferring it from time. Perhaps you could propose a new spec for that. And
> high resolution profiling can be done using developer tools, or by building
> a benchmark that runs many iterations.
>
> James
>
> On Tue, Mar 13, 2012 at 10:17 AM, Noah Mendelsohn <nrm@arcanedomain.com
> <mailto:nrm@arcanedomain.com>> wrote:
>
>     This is a comment on the Last Call Working Draft "High Resolution Time"
>     [1].
>
>     First of all, thank you for doing this work. Having over a period of
>     many years worked on the development of high-performance systems, the
>     availability of a monotonic, high resolution (pseudo) clock will be a
>     significant improvement to the Web platform IMO.
>
>     This specific concern I'd like to raise is with section 4.4 "Monotonic
>     clock", which says [2]:
>
>     "The time values returned when calling the now method MUST be
>     monotonically increasing and not subject to system clock adjustments or
>     system clock skew. The difference between any two chronologically
>     recorded time values returned from the now method MUST never be negative. "
>
>     and section 4.2 which says "4.2 The DOMHighResTimeStamp Type" which
>     says [3]:
>
>     "Type Definition DOMHighResTimeStamp
>
>         A DOMHighResTimeStamp represents a number of milliseconds accurate
>     to at least a tenth of a millisecond."
>
>     It's a nice characteristic for high resolution clocks to have
>     sufficient resolution that the difference between two successive
>     readings will always be positive, never zero. This facilitates the use
>     of such time values for the generation of unique timestamps, and also
>     improves their utility for timing small amounts of code on
>     high-performance processors.
>
>     I know this is an old and obscure reference, but an example of a design
>     that attends to this need is the IBM 370 STORE CLOCK instruction, which
>     (as documented on page 6 of [4]) is designed always to increment
>     between successive stores. The reasons are the same ones described
>     above: timestamps can be used as unique identifiers, and the resolution
>     is sufficient to provide useful timing even for small amounts of code.
>
>     In practice, implementation would require that a browser would have to
>     have access to a hardware clock with sufficient resolution, or else
>     (and this is a drawback) would have to artificially delay in the case
>     where there's a risk of failure to advance.
>
>     Anyway, having clocks always move forward between stores is a desirable
>     feature. If this is viewed as too aggressive to set as a requirement, I
>     would suggest at least the following rewording of the quote from 4.2:
>
>     "Type Definition DOMHighResTimeStamp
>
>         A DOMHighResTimeStamp represents a number of milliseconds accurate
>     to at least a tenth of a millisecond. Implementations SHOULD provide
>     sufficient accuracy that successive accesses to now() will return
>     differing values."
>
>     Thank you for your consideration of this suggestion. Also: I am
>     speaking here for myself, and in particular not for the TAG (which has
>     not considered [1]), or for any of the other working groups or
>     organizations with which I am affiliated.
>
>     Noah
>
>
>
>     [1] http://www.w3.org/TR/2012/WD-__hr-time-20120313/
>     [2] http://www.w3.org/TR/2012/WD-__hr-time-20120313/#sec-__monotonic-clock
>     [3]
>     http://www.w3.org/TR/2012/WD-__hr-time-20120313/#sec-__DOMHighResTimeStamp
>     [4]
>     http://bitsavers.org/pdf/ibm/__370/princOps/GA22-7000-0_370___Principles_Of_Operation_Jun70.__pdf
>
>

Received on Tuesday, 13 March 2012 20:24:26 UTC