RE: rogue comment: IEEE 754R and Reproducibility

["David James" <dvj@xxxxxxxxxxxx>]

Nick,

> > 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.


> > 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.


> > 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.

While the number of individual promotions did indeed double
(the key motivation for such large joint projects), PowerPoint
allowed the technical issues to be sidestepped until both
sides were overly committed to the technical compromises
mandated by VP-level directives.

In that sense, I am certainly not making the same mistake
as Intel and HP, since my "company" is much smaller and
my wife is much less bureaucratic(:>). 

Cheers,
DVJ


> > -----Original Message-----
> > From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Nick
> > Maclaren
> > Sent: Friday, June 22, 2007 10:06 AM
> > To: stds-754@xxxxxxxx
> > Subject: Re: rogue comment: IEEE 754R and Reproducibility
> >
> >
> > "David James" <dvj@xxxxxxxxxxxx> wrote:
> > > > You are therefore demanding a global, absolute, precise clock model
> > > > - and nobody in the parallel field believes that such a thing is
> > > > even theoretically possible,
> > >
> > > The possibility of synchronizing the clocks to within less than
> > > one instruction (on a many-core chip) or one read/write transaction
> > > (on a many-chip configuration) is certainly possible and practical.
> >
> > Firstly, while what you say is just about possible (at CONSIDERABLE
> > cost) today, nobody in the area is convinced that will be true even
> > tomorrow, let alone the day after.  The difference between 4 cores
> > and 64 cores is more than you realise.
> >
> > Secondly, and more importantly, that is not enough and does not meet
> > the requirement I described.  If you have N cores and a basic time
> > of T, you need clocks precise to T/N to ensure consistent ordering
> > of the CPUs.  That is a gross simplification, of course.
> >
> > Now consider 64 cores, each running at 4 GHz - just HOW are you
> > going to keep those clocks consistent?
> >
> > > Its probably not the right solution, though.
> >
> > Well, THERE you are right.
> >
> > > > > in combination with even tolerable efficiency OR scalability.
> > >
> > > Its not clear to me that one must serialize all operations.
> > > I'm not an expert, but it would seem to be sufficient
> > > to ensure that the dependency graphs are the same,
> > > and these do allow for parallelism.
> >
> > If you can invent an algorithm that is guaranteed to preserve the
> > dependency graph of an arbitrary serial program when allowing it to
> > be parallelised to even good efficiency, I will bow down and worship
> > you as at least a minor deity.  For heaven's sake - does nobody EVER
> > learn anything from history?
> >
> > Well, as we all know, the classic answer is "no".  People like me
> > don't count.  You are making EXACTLY the same mistake that Intel and
> > HP did with the Itanic in the mid-1990s - I told them that they
> > couldn't deliver the compiler technology, and I was right.  I am not
> > a second Alan Turing, but merely someone who had observed 25 years
> > of dismal failure by the best computer scientists in the world!
> >
> > > Admittedly not as fast as possible, if associativity and commutativity
> > > were to be assumed, but not as slow as serialized operations.
> >
> > Yeah.  Typically you can get something like O(log(N)) speedup by using
> > N cores.  Big deal.
> >
> >
> > 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