[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: rogue comment: IEEE 754R and Reproducibility (revised to clocks and mistakes :>)
Nick,
That is why every chip manufacturer is going away from
single clocks as fast as they can.
There is a bit of confusion herein.
There are two time of clocks:
1) Circuit clocks, that run processor pipeline, etc.
2) Timing clocks, that provide accurte time-of-day
synchronization between entities.
Examples of (2) include:
IEEE p1588
IEEE p802.1as
I believe you quotes to the literature are on the topic of (1),
my statement was on the topic of (2).
That is why every chip manufacturer is going away from
single clocks as fast as they can.
The real reason for going away from single clocks has more
to do with independent power-controlled domains, not the
power inefficiencies of running in lock-step. Regardless,
one has to assume that clocks of type (1) will not be
common across the chip and hence should not be used in
place of (2), as is oftentimes (falsely) assumed by the
CPU instruction-set definitions providing access to
synchronized time-of-day values.
Really? I don't think that you know its background.
Only as much as one can, from working at both HP and Intel,
with affected associates at both.
the (main) technical mistake, and not the managerial ones.
IMHO, the managerial mistakes are the primary cause for
most technical mistakes. You can't really separate the two.
I would certainly hesitate to state there was any one
"(main)" technical mistake; there were many. The "main"
ranking depends on your area of interest.
-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Nick
Maclaren
Sent: Friday, June 22, 2007 12:18 PM
To: stds-754@xxxxxxxx
Subject: RE: rogue comment: IEEE 754R and Reproducibility
"David James" <dvj@xxxxxxxxxxxx> wrote:
Now consider 64 cores, each running at 4 GHz - just HOW are you
going to keep those clocks consistent?
Its easy when they are all on one chip; a simple strobe line
(actually two) will do. Of course, this gets harder as the clock
rates become variable/inconsistent due to power-savings adjustments
(power-down granularity is trending towards per-processor or finer).
Not that I do _not_ think this is a good solution; simply that
I doubted the accuracy of your assumption.
Sigh. Take a look at papers on practical chip designs and, in
particular, the problems of clocking. Most were claiming that
it already accounts for a large amount of the power (half?) and
is super-linear in the size of the chip. That is why every chip
manufacturer is going away from single clocks as fast as they can.
Like everything else, if you have no other constraints, you can
solve any one problem. But real life isn't like that.
dependency graph of an arbitrary serial program when allowing it to
be parallelised to even good efficiency, I will bow down and worship
^^^^^^^^^^^^^^^^^^^^
For repeatable results, efficiency is not a requirement.
Please get real. If I am trying to debug a program that takes
10 minutes to run, optimised, being told that I need to run it in
a hundredfold slower mode to debug it isn't helpful.
You are making EXACTLY the same mistake that Intel and
HP did with the Itanic in the mid-1990s
The basic problem with Itanic was the dillusion of two large
bureaucratic PowerPoint driven organizations that working
together would be more efficient, since their partner could
not possibly be as inefficient/political as themselves.
Really? I don't think that you know its background. That was
certainly a factor, but I was referring to the (main) technical
mistake, and not the managerial ones.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679