W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2012

Re: Comment on High Resolution Time Last Call Draft

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 13 Mar 2012 12:03:54 -0700
Message-ID: <CAPVJQikuLBwYFiewJ9oPMknhnJQtrawB39dABTu0HOk=qPB1rw@mail.gmail.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: public-web-perf@w3.org
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

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.


On Tue, Mar 13, 2012 at 10:17 AM, Noah Mendelsohn <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 19:04:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC