Terje Mathisen [2021-08-13 11:00:26] wrote:
> John Levine wrote:
>> According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>>> So, is the phenomenon real? (I assume Google is seeing what they are seeing).
>> Back in the 1950s and 1950s computers were, by our standards
>> extremely unreliable.
> Even in the seventies mainframes competed on how fast they could snapshot,
> crash, reboot the os, reload the snapshot and recover in order to
> handle faults.
> :-)

Of course, that's no help when the glitch happened tens of snapshots ago
(or doesn't cause the machine to crash and "just" leads to the
payroll's output to be way out).

Stefan

MitchAlsup wrote:
> On Wednesday, August 11, 2021 at 5:35:02 PM UTC-5, EricP wrote:
> <
>> I read it as a plea for more automatic internal self checks
>> so they can detect the intermittent problems when they occur.
>> Equivalent to memory ECC but for logic.
> <
> Expensive. Consider, for the moment, how much logic would it take to
> verify a multiplier gave you the correct bit patterns ?
> <
> Store {registers, caches, SRAM, DRAM} are all easily protected using various
> kinds of error detecting and correcting codes. Buses and wires that simply
> move bits around can utilize the same.
> <
> Verifying arithmetic is hard, verifying control units is even harder. I once
> worked on the design of a machine which could deliver all of the correct
> bit patterns to all the correct locations, taking the correct number of
> cycles, and having done all this in the WRONG sequence order !!

If they had byte parity on the buses and registers,
and parity on the control signals, that's a start.

A little rummaging about finds quite a few patents for
ALU's that calculate byte parity with the result,
which is then compared with the result parity.

For example this is from 1974 (web page is garbled, the PDF is not)
but there are references to, for example, IBM patents from 1960
for "Error checking system for a parallel adder"

Below integrates the carry lookahead generation with parity lookahead
for ADD, SUB, AND, OR, XOR (section 5 of PDF gives the logic equations).

Parity predicting and checking logic for
carry look-ahead binary adder, 1974
https://patents.google.com/patent/US3925647A/en?oq=3925647

>> If they can't determine which cpu's are hurting and when,
>> they can't quit doing it.
> <
> They can take all of the suspected units and turn the clock multiplier down
> by 1 or 2 units of multiplication. That is what I meant by quit doing that.

The problem is identifying the suspected units.
The paper said they passed the standard diagnostics.
Certain units failed on certain calculations under certain conditions,
detected later by comparing outputs from multiple units.

On Thursday, August 12, 2021 at 10:00:09 PM UTC-5, John Levine wrote:
> According to Stephen Fuld <sf...@alumni.cmu.edu.invalid>:
> >So, is the phenomenon real? (I assume Google is seeing what they are seeing).
>
> Back in the 1950s and 1950s computers were, by our standards extremely unreliable.
>
> In 1948 the IBM SSEC did everything twice in parallel and compared.
> Programmers had to hang around while their programs ran to recover
> manually when the compares failed, or other things failed, and get it
> restarted.
>
> The IAS machine in Princeton sort of started working in 1951 but it
> required huge effort and another year (and as it turned out huge
> cooling) to get it to work for more than a few seconds at a time.
>
> The IBM 704 was more reliable than its predecessors, partly because they had learned
> more about making reliable vacuum tubes, and mostly because it used core memory rather
> than flaky Williams tubes or Selectrons. Nonetheless, I hear that the maximum practical
> size for a Fortran program was limited not by the size of memory but by how long the
> compiler could run before the hardware flaked and it crashed.
>
> The details of the mercurial failures aren't the same as the failures of vacuum tubes,
> of course, but they share the fundamental problem of trying to build digital systems
> out of fundamentally analog components.
<
Digital gates are simply analog gates with maximum noise rejection.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Friday, August 13, 2021 at 4:00:30 AM UTC-5, Terje Mathisen wrote:
> John Levine wrote:
> > According to Stephen Fuld <sf...@alumni.cmu.edu.invalid>:
> >> So, is the phenomenon real? (I assume Google is seeing what they are seeing).
> >
> > Back in the 1950s and 1950s computers were, by our standards extremely unreliable.
> Even in the seventies mainframes competed on how fast they could
> snapshot, crash, reboot the os, reload the snapshot and recover in order
> to handle faults.
<
Why did this snap and reboot never make it into a benchmark ???
<
> :-)
>
> I think they got that process down to a few seconds?
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Friday, August 13, 2021 at 6:02:10 AM UTC-5, Michael S wrote:
> On Friday, August 13, 2021 at 12:00:30 PM UTC+3, Terje Mathisen wrote:
> > John Levine wrote:
> > > According to Stephen Fuld <sf...@alumni.cmu.edu.invalid>:
> > >> So, is the phenomenon real? (I assume Google is seeing what they are seeing).
> > >
> > > Back in the 1950s and 1950s computers were, by our standards extremely unreliable.
> > Even in the seventies mainframes competed on how fast they could
> > snapshot, crash, reboot the os, reload the snapshot and recover in order
> > to handle faults.
> > :-)
> >
> > I think they got that process down to a few seconds?
> > Terje
> >
> > --
> > - <Terje.Mathisen at tmsw.no>
> > "almost all programming can be viewed as an exercise in caching"
> My impression was that in the second half of the 70s IBM started to take reliability
> seriously and very quickly achieved huge progress on this front.
<
Coincidentally, this coincided with the addition of virtual memory to the
machines.........
<
> The same happened to [mainframe] security few years later.
> But I was not around back then.

On Friday, August 13, 2021 at 10:33:42 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Wednesday, August 11, 2021 at 5:35:02 PM UTC-5, EricP wrote:
> > <
> >> I read it as a plea for more automatic internal self checks
> >> so they can detect the intermittent problems when they occur.
> >> Equivalent to memory ECC but for logic.
> > <
> > Expensive. Consider, for the moment, how much logic would it take to
> > verify a multiplier gave you the correct bit patterns ?
> > <
> > Store {registers, caches, SRAM, DRAM} are all easily protected using various
> > kinds of error detecting and correcting codes. Buses and wires that simply
> > move bits around can utilize the same.
> > <
> > Verifying arithmetic is hard, verifying control units is even harder. I once
> > worked on the design of a machine which could deliver all of the correct
> > bit patterns to all the correct locations, taking the correct number of
> > cycles, and having done all this in the WRONG sequence order !!
> If they had byte parity on the buses and registers,
> and parity on the control signals, that's a start.
>
> A little rummaging about finds quite a few patents for
> ALU's that calculate byte parity with the result,
> which is then compared with the result parity.
<
I worked on a machine that calculated "result parity" as an additional
circuit path through the carry chain. Adders, in this respect, are easy
to check, multiply and divide are the hard ones.
>
> For example this is from 1974 (web page is garbled, the PDF is not)
> but there are references to, for example, IBM patents from 1960
> for "Error checking system for a parallel adder"
>
> Below integrates the carry lookahead generation with parity lookahead
> for ADD, SUB, AND, OR, XOR (section 5 of PDF gives the logic equations).
>
> Parity predicting and checking logic for
> carry look-ahead binary adder, 1974
> https://patents.google.com/patent/US3925647A/en?oq=3925647
> >> If they can't determine which cpu's are hurting and when,
> >> they can't quit doing it.
> > <
> > They can take all of the suspected units and turn the clock multiplier down
> > by 1 or 2 units of multiplication. That is what I meant by quit doing that.
<
> The problem is identifying the suspected units.
<
In Googles case, downclocking all of the farm would gain a lot in
reliability.
<
> The paper said they passed the standard diagnostics.
<
Std diagnostics are not run at corner voltage and temperatures.
<
> Certain units failed on certain calculations under certain conditions,
> detected later by comparing outputs from multiple units.

On 8/12/2021 7:10 AM, Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> Expensive. Consider, for the moment, how much logic would it take to
>> verify a multiplier gave you the correct bit patterns ?
>
> Compute the hexadecimal digital root (repeated digital sum) dr of the
> multipliers a and b, and the result p. Now,
>
> dr(p)=dr(dr(a)*dr(b))

Ahhh! Brings back memories of "casting out nines". :-)

While you could probably compute dr(a) and dr(b) in parallel with the
multiply, you can't start computing dr(p) until you have at least the
low order digits of the multiply, and can't finish it until the multiply
is complete. So how many cycles do you have to add to the multiply
instruction to complete the check?

> Should be pretty easy to check, and you can use other bases than hex
> to vary cost and precision. You can also use the digital root for
> checking addition and subtraction.

Yes, but as pointed out elsewhere, those may be better handled with
parity. Of course YMMV.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 8/12/2021 7:10 AM, Anton Ertl wrote:
>> MitchAlsup <MitchAlsup@aol.com> writes:
>>> Expensive. Consider, for the moment, how much logic would it take to
>>> verify a multiplier gave you the correct bit patterns ?
>>
>> Compute the hexadecimal digital root (repeated digital sum) dr of the
>> multipliers a and b, and the result p. Now,
>>
>> dr(p)=dr(dr(a)*dr(b))
>
>Ahhh! Brings back memories of "casting out nines". :-)
>
>While you could probably compute dr(a) and dr(b) in parallel with the
>multiply, you can't start computing dr(p) until you have at least the
>low order digits of the multiply, and can't finish it until the multiply
>is complete. So how many cycles do you have to add to the multiply
>instruction to complete the check?

Hardly matters, because the check is not necessary for using the
result. I.e., pass p on to consumers while doing the check, but do
not retire the multiply until the check is complete. If the check
fails, you can do any of machine-check, or exception, or retry, and
consumers of the broken result will not retire.

>> Should be pretty easy to check, and you can use other bases than hex
>> to vary cost and precision. You can also use the digital root for
>> checking addition and subtraction.
>
>Yes, but as pointed out elsewhere, those may be better handled with
>parity.

Parity looks to me like the digital root with base 2. With larger
bases, you have a better probability of catching errors beyond
single-bit errors.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Michael S <already5chosen@yahoo.com>:
>My impression was that in the second half of the 70s IBM started to take reliability
>seriously and very quickly achieved huge progress on this front.
>The same happened to [mainframe] security few years later.
>But I was not around back then.

IBM always took hardware reliability seriously. I understand that one of the rules
for a new generation of hardware was that it had to be uniformly cheaper, faster,
and more reliable than its predecessor. But reliability, particularly in large complex
systems, was and is hard.

When I was playing with Princeton's 360/91 around 1970, it would crash
every weekday afternoon. They assumed there was some job someone was
running that triggered an OS flaw, but they never figured how who or
what. Even my lowly Fortran programs died with a machine check once or
twice.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 8/13/21 2:10 PM, John Levine wrote:
[snip]
>
> When I was playing with Princeton's 360/91 around 1970, it would crash
> every weekday afternoon. They assumed there was some job someone was
> running that triggered an OS flaw, but they never figured how who or
> what. Even my lowly Fortran programs died with a machine check once or
> twice.

I hope that wasn't me. I knew of only one time I crashed it due to a JCL error.

Perhaps you remember when the cooling system failed and the /91 was down for a
week or so. I remember (perhaps incorrectly) that the floating point
circuitry was tuned by delay lines that had to be tuned every time they
replaced the semiconductors, and this took some time.

brian

On Friday, August 13, 2021 at 10:16:55 AM UTC-6, MitchAlsup wrote:

> I worked on a machine that calculated "result parity" as an additional
> circuit path through the carry chain. Adders, in this respect, are easy
> to check, multiply and divide are the hard ones.

Integer multiply without an overflow can be checked modulo 7 or
modulo 15 easily, if not for parity.

John Savard

On Friday, August 13, 2021 at 10:33:44 AM UTC-6, Stephen Fuld wrote:

> Ahhh! Brings back memories of "casting out nines". :-)

Yes, except you cast out sevens or fifteens or two hundred and fifty-fives.

John Savard

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>If the check
>fails, you can do any of machine-check, or exception, or retry, and
>consumers of the broken result will not retire.

In the light of the discussion of overaggressive DFVS being the
culprit for such failures, a good way to deal with such failures is to
lower frequency or increase voltage (and record that this was
necessary, so the CPU becomes permanently less aggressive in DFVS),
and retry.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, August 13, 2021 at 12:16:55 PM UTC-4, MitchAlsup wrote:
[snip]
> I worked on a machine that calculated "result parity" as an additional
> circuit path through the carry chain. Adders, in this respect, are easy
> to check, multiply and divide are the hard ones.

Todd Austin's "DIVA: A Reliable Substrate for Deep Submicron
Microarchitecture Design" comes to mind. The check logic was
much simpler (and more parallel since data dependencies do
not exist for computations in the past) than the OoOE engine of
a typical high performance processor.

Multiplies are still very expensive in energy per computation, so this
form of redundant computation might not be attractive.

[snip]
> In Googles case, downclocking all of the farm would gain a lot in
> reliability.

Since the performance of many workloads does not scale
linearly with clock speed and the downclocking would not have
to be extreme, one might conclude that Google was not
particularly aware of the problem before or simply did not care
much about result reliability.

For search results, video delivery, ad delivery, and other Google-
based services, occasional unreliability is probably not
important. For external customer's use of cloud computing,
this might be more problematic; however, "cheap beats
expensive" may be a variation on the theme of Kahan's quote
"The Fast drives out the Slow even if the Fast is wrong."

[snip]
> Std diagnostics are not run at corner voltage and temperatures.

I suspect Google's data centers are using corner cases to reduce
the electricity bill (power and cooling).

On Saturday, August 14, 2021 at 3:14:15 PM UTC-5, Paul A. Clayton wrote:
> On Friday, August 13, 2021 at 12:16:55 PM UTC-4, MitchAlsup wrote:
> [snip]
> > I worked on a machine that calculated "result parity" as an additional
> > circuit path through the carry chain. Adders, in this respect, are easy
> > to check, multiply and divide are the hard ones.
> Todd Austin's "DIVA: A Reliable Substrate for Deep Submicron
> Microarchitecture Design" comes to mind. The check logic was
> much simpler (and more parallel since data dependencies do
> not exist for computations in the past) than the OoOE engine of
> a typical high performance processor.
>
> Multiplies are still very expensive in energy per computation, so this
> form of redundant computation might not be attractive.
>
> [snip]
> > In Googles case, downclocking all of the farm would gain a lot in
> > reliability.
> Since the performance of many workloads does not scale
> linearly with clock speed and the downclocking would not have
> to be extreme, one might conclude that Google was not
> particularly aware of the problem before or simply did not care
> much about result reliability.
<
Google's whole computational model is that any machine can crash
at any point in time and Google still provides almost every one with
almost everything they ask for.
>
> For search results, video delivery, ad delivery, and other Google-
> based services, occasional unreliability is probably not
> important.
<
Designed in to tolerate crashes almost anywhere at almost any time.
<
This is a new phenomenon: the machines did not crash so their
system did not detect and recover. Google probably would have
liked the machines to crash instead of delivering bad results.
They are set up for crashes not silently delivering bad results.
<
> For external customer's use of cloud computing,
> this might be more problematic; however, "cheap beats
> expensive" may be a variation on the theme of Kahan's quote
> "The Fast drives out the Slow even if the Fast is wrong."
>
> [snip]
> > Std diagnostics are not run at corner voltage and temperatures.
> I suspect Google's data centers are using corner cases to reduce
> the electricity bill (power and cooling).

On 8/13/2021 10:23 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> On 8/12/2021 7:10 AM, Anton Ertl wrote:
>>> MitchAlsup <MitchAlsup@aol.com> writes:
>>>> Expensive. Consider, for the moment, how much logic would it take to
>>>> verify a multiplier gave you the correct bit patterns ?
>>>
>>> Compute the hexadecimal digital root (repeated digital sum) dr of the
>>> multipliers a and b, and the result p. Now,
>>>
>>> dr(p)=dr(dr(a)*dr(b))
>>
>> Ahhh! Brings back memories of "casting out nines". :-)
>>
>> While you could probably compute dr(a) and dr(b) in parallel with the
>> multiply, you can't start computing dr(p) until you have at least the
>> low order digits of the multiply, and can't finish it until the multiply
>> is complete. So how many cycles do you have to add to the multiply
>> instruction to complete the check?
>
> Hardly matters, because the check is not necessary for using the
> result. I.e., pass p on to consumers while doing the check, but do
> not retire the multiply until the check is complete. If the check
> fails, you can do any of machine-check, or exception, or retry, and
> consumers of the broken result will not retire.

This is getting beyond my expertise, but it sort of looks like you are
adding n stages to the pipeline (where n is the number of cycles needed
to compute the dr(p) and do the compare). So you may need resources to
keep more instructions in flight, etc. Note that this is not just for
multiply/divide, but also add/subtract, and load/store (assuming you do
additions in address generation). I would expect some performance hit,
but I don't know how much.

>>> Should be pretty easy to check, and you can use other bases than hex
>>> to vary cost and precision. You can also use the digital root for
>>> checking addition and subtraction.
>>
>> Yes, but as pointed out elsewhere, those may be better handled with
>> parity.
>
> Parity looks to me like the digital root with base 2. With larger
> bases, you have a better probability of catching errors beyond
> single-bit errors.

Good point. The trade off is the ability to compute parity without any
extra cycles. Perhaps the optimal solution is parity for add/subtract
and address generation, but digit root 16 for multiply/divide.

We are hindered in this by lack of detailed knowledge of what part of
the chip failed. Is it reasonable to assume that the failures that
escaped testing by the manufacturer are the same type and relative
frequency as those that didn't, just less frequent? I don't know.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 8/13/2021 10:23 AM, Anton Ertl wrote:

>> Hardly matters, because the check is not necessary for using the
>> result. I.e., pass p on to consumers while doing the check, but do
>> not retire the multiply until the check is complete. If the check
>> fails, you can do any of machine-check, or exception, or retry, and
>> consumers of the broken result will not retire.
>
> This is getting beyond my expertise, but it sort of looks like you are
> adding n stages to the pipeline (where n is the number of cycles needed
> to compute the dr(p) and do the compare).

Is a multiplier even an area where things are likely to fail?

I would assume that one of the gazilliions of multiplexer which
just delivers that one wrong bit can be as devastating, and much
harder to catch.

On 8/15/2021 12:55 PM, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 8/13/2021 10:23 AM, Anton Ertl wrote:
>
>>> Hardly matters, because the check is not necessary for using the
>>> result. I.e., pass p on to consumers while doing the check, but do
>>> not retire the multiply until the check is complete. If the check
>>> fails, you can do any of machine-check, or exception, or retry, and
>>> consumers of the broken result will not retire.
>>
>> This is getting beyond my expertise, but it sort of looks like you are
>> adding n stages to the pipeline (where n is the number of cycles needed
>> to compute the dr(p) and do the compare).
>
> Is a multiplier even an area where things are likely to fail?
>
> I would assume that one of the gazilliions of multiplexer which
> just delivers that one wrong bit can be as devastating, and much
> harder to catch.

I would assume that also, but as I said in the part of my post after the
part you responded to, we need a lot more knowledge about what is happening.

Even if the errors that occur in Google's paper are the same as those
that occur more frequently in manufacturer's tests (and we don't know
that), I don't know if manufacturers do detailed analysis of what fails
in their tests or just bin them down to where they do pass. It seems
like analysis would be a good idea, for if a specific area fails more
often, it might make sense to do something about that part of the
design, if it can improve the yield of higher frequency binned chips.
But as I said, I am WAY beyond my expertise here.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Sunday, August 15, 2021 at 2:55:25 PM UTC-5, Thomas Koenig wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
> > On 8/13/2021 10:23 AM, Anton Ertl wrote:
>
> >> Hardly matters, because the check is not necessary for using the
> >> result. I.e., pass p on to consumers while doing the check, but do
> >> not retire the multiply until the check is complete. If the check
> >> fails, you can do any of machine-check, or exception, or retry, and
> >> consumers of the broken result will not retire.
> >
> > This is getting beyond my expertise, but it sort of looks like you are
> > adding n stages to the pipeline (where n is the number of cycles needed
> > to compute the dr(p) and do the compare).
<
> Is a multiplier even an area where things are likely to fail?
<
Anecdotal information:
The CDC 7600 could crash as the result of running certain data patterns
through DGEMM (semi-optimized matrix multiply). The rest of the CPU
was capable of feeding the multiplier work every cycle and the whole
system was operating much like a DMA device that happened to mangle
data on its way through. A particular data pattern would cause worse
case power supply consumption at the multiplier board--setting up standing
waves between the multiplier and the power supply of that sub-rack. When
the standing wave was bigger than the noise immunity of the receiving gates,
corruption occurred (both address and data) and the machine would crash.
<
IBM 360/91 cycled its multiplier 3 times per main CPU cycle--this enabled
them to perform a multiply every clock in a pipelined fashion and this required
those Earle latches for historical reference. The timing of the multiplier was
performed with delay lines which had to be "adjusted" if any gate in the multi-
plier needed to be changed during service. Until the delay lines were retimed
the multiplier could very easily cause a Machine Check.
<
So, yes, multipliers are as tricky as any other large block.
>
> I would assume that one of the gazilliions of multiplexer which
> just delivers that one wrong bit can be as devastating, and much
> harder to catch.
<
These are caught with parity and ECC--which is a lot easier that figuring out
if what came out of the multiplier was the correct bit pattern. Although it
occurs to me that vertical and diagonal parity in a multiplier tree (before the
adder with the carry chain) might detect the multiplier data corruption.

On Sunday, August 15, 2021 at 3:17:26 PM UTC-5, Stephen Fuld wrote:
> On 8/15/2021 12:55 PM, Thomas Koenig wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
> >> On 8/13/2021 10:23 AM, Anton Ertl wrote:
> >
> >>> Hardly matters, because the check is not necessary for using the
> >>> result. I.e., pass p on to consumers while doing the check, but do
> >>> not retire the multiply until the check is complete. If the check
> >>> fails, you can do any of machine-check, or exception, or retry, and
> >>> consumers of the broken result will not retire.
> >>
> >> This is getting beyond my expertise, but it sort of looks like you are
> >> adding n stages to the pipeline (where n is the number of cycles needed
> >> to compute the dr(p) and do the compare).
> >
> > Is a multiplier even an area where things are likely to fail?
> >
> > I would assume that one of the gazilliions of multiplexer which
> > just delivers that one wrong bit can be as devastating, and much
> > harder to catch.
> I would assume that also, but as I said in the part of my post after the
> part you responded to, we need a lot more knowledge about what is happening.
>
> Even if the errors that occur in Google's paper are the same as those
> that occur more frequently in manufacturer's tests (and we don't know
> that), I don't know if manufacturers do detailed analysis of what fails
> in their tests or just bin them down to where they do pass. It seems
> like analysis would be a good idea, for if a specific area fails more
> often, it might make sense to do something about that part of the
> design, if it can improve the yield of higher frequency binned chips.
> But as I said, I am WAY beyond my expertise here.
<
But your intuition is good.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Saturday, August 14, 2021 at 2:14:15 PM UTC-6, Paul A. Clayton wrote:

> Since the performance of many workloads does not scale
> linearly with clock speed

Huh, what?

Whatever the workload, of course performance will scale linearly with
clock speed unless:

- the computer is idle for periods of time between I/O requests, or
- when the clock speed is slowed, more processors are put to work on the
problem in parallel

But if what you have is a computer doing computations, if you change
its clock speed, you change how long the computation takes in exact
proportion.

John Savard

On Saturday, August 14, 2021 at 2:14:15 PM UTC-6, Paul A. Clayton wrote:

> Todd Austin's "DIVA: A Reliable Substrate for Deep Submicron
> Microarchitecture Design" comes to mind. The check logic was
> much simpler (and more parallel since data dependencies do
> not exist for computations in the past) than the OoOE engine of
> a typical high performance processor.

I looked it up when I saw this.

But the very first diagram in the paper (Figure 1) shows why the idea
never took off. It shows the checker logic as being located *on the
critical path*, delaying commit of results from the normal out-of-order
core preceding it!

While I don't think that _all_ additional delay can be avoided, a
practical design would have most of the checking done in *parallel*
with computation so that performance impact is kept to an
absolute minimum.

John Savard

On Sunday, August 15, 2021 at 3:06:43 PM UTC-6, MitchAlsup wrote:
> A particular data pattern would cause worse
> case power supply consumption at the multiplier board--setting up standing
> waves between the multiplier and the power supply of that sub-rack.

It was not designed so that the power supply had a capacity in excess
of that required for all possible operations and states of the machine?

What on Earth were they _thinking_?

Of course, even IBM designed some of their line printers so that they
were unable to fire all the print hammers at once should that be
required, so Control Data isn't the only company with over-optimistic
engineers.

John Savard

On Sunday, August 15, 2021 at 5:36:08 PM UTC-5, Quadibloc wrote:
> On Saturday, August 14, 2021 at 2:14:15 PM UTC-6, Paul A. Clayton wrote:
>
> > Since the performance of many workloads does not scale
> > linearly with clock speed
> Huh, what?
<
CPU speeds go up, interconnect speeds are already maxed out,
DRAM latencies are not improving.
>
> Whatever the workload, of course performance will scale linearly with
> clock speed unless:
<
You are waiting on memory for a higher percentage of your clock cycles.
>
> - the computer is idle for periods of time between I/O requests, or
> - when the clock speed is slowed, more processors are put to work on the
> problem in parallel
>
> But if what you have is a computer doing computations, if you change
> its clock speed, you change how long the computation takes in exact
> proportion.
>
> John Savard

On 8/15/21 6:44 PM, Quadibloc wrote:
> On Sunday, August 15, 2021 at 3:06:43 PM UTC-6, MitchAlsup wrote:
>> A particular data pattern would cause worse
>> case power supply consumption at the multiplier board--setting up standing
>> waves between the multiplier and the power supply of that sub-rack.
>
> It was not designed so that the power supply had a capacity in excess
> of that required for all possible operations and states of the machine?
>
> What on Earth were they _thinking_?
>
> Of course, even IBM designed some of their line printers so that they
> were unable to fire all the print hammers at once should that be
> required, so Control Data isn't the only company with over-optimistic
> engineers.
>
> John Savard
>

I have a fairly current laptop that can consume more power than its AC
Adaptor can provide, and if you leave it just running it can drain the
battery and go into a low battery shutdown while plugged in.

At which point the battery recharges so you can start something, leave
it running and come back to find it has shut itself down with a log of
low battery and the machine has a fully charged battery.

Wouldn't be so bad if it knew enough to slow down the processor to drop
power usage as the battery got lower, but it doesn't give that sort of
option.