Add native QPC to base::Time* conversion on Windows.

Add native QPC to base::Time* conversion on Windows.
BUG=137792
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=149801

[brianderson, 2012-08-02 00:05:21]

Split the base::Time changes of http://codereview.chromium.org/10825053/ into
its own patch.  

Requesting lgtm carryover.

[brianderson, 2012-08-02 01:45:42]

John came up with a good idea - replace the floating point logic with integer
logic.  This way, we get the best precision and it should be faster than the
floating point math.

[jbates, 2012-08-02 03:10:34]

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc
File base/time_win.cc (right):

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc#ne...
base/time_win.cc:382: : ticks_per_second_(0),
what's the reason for changing to per_second? seems simpler to stick with
per_microsecond math?

[jar (doing other things), 2012-08-02 03:13:20]

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc
File base/time_win.cc (right):

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc#ne...
base/time_win.cc:376: return qpc_value * Time::kMicrosecondsPerSecond /
ticks_per_second_;
nit: 2 character indent from start of "if"

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc#ne...
base/time_win.cc:407: return now.QuadPart * Time::kMicrosecondsPerSecond /
ticks_per_second_;
I think this is going to work ok (working with integers instead of a float)...
but I'm not sure.

Can you add a comment that suggests when we'll see an overflow in this integer
multiplication (that precedes the division)?

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc#ne...
base/time_win.cc:415: // Cached clock frequency -> microseconds. This assumes
that the clock
Comment should be changed or removed.

[brianderson, 2012-08-02 19:04:14]

Wish we had 128 bit integers.  Do we have any kind of "big number" class in
base?

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc
File base/time_win.cc (right):

https://chromiumcodereview.appspot.com/10843038/diff/2003/base/time_win.cc#ne...
base/time_win.cc:382: : ticks_per_second_(0),
Using ticks per second, we are dividing by the actual value returned by
QueryPerformanceFrequency yielding the most accurate scaling.  The conversion to
microseconds in the end, however, causes us to overflow sooner (1e6 times more
often).

Using ticks per microsecond, we only overflow when the QPC overflows and we only
have to do a single division to convert.  However, we lose 20 bits (2^20 ~= 1e6)
of precision when scaling.

Using ticks per millisecond could be a compromise between the two extremes.  We
wouldn't overflow as often as ticks_per_second and we would only lose 10 bits
(2^10 ~= 1e3) of precision when scaling.

Assuming a 1 Ghz = 1e9 Hz QPC:
ticks_per_second will overflow in 2^(64-20) / 1e9 = 17592 seconds = 4.8 hrs.
ticks_per_millisconds will overflow 2^(64-10) / 1e9 = 18014398 seconds = 208
days.
ticks_per_microsecond will overflow 2^64 / 1e9 = 213504 days = 600 years.

Seems like we should stick to ticks_per_microsecond and hope the 20 bits of
precision lost is ok...

[brianderson, 2012-08-02 20:15:08]

While John and I were trying to figure out how to get a 128 bit number in here,
John came up with another great idea that avoids both the overflow and precision
issues by calculating microseconds in a slightly round about manner.  See
implementation of QPCValueToMicroseconds.

[jbates, 2012-08-02 20:18:14]

LGTM

[jar (doing other things), 2012-08-03 02:01:19]

LGTM

As per our discussion... you guys should be alert to possible performance issues
in this hand-crafted 128 bit math activity.  Even 64 bit math is pretty
expensive on our 32 bit builds.

[commit-bot: I haz the power, 2012-08-03 02:03:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brianderson@chromium.org/10843038/2006

[commit-bot: I haz the power, 2012-08-03 07:22:53]

Change committed as 149801