1 Jan
2018
1 Jan
'18
5:15 a.m.
From: Peter Corlett
since we have computers with multiple gigabytes of
RAM, it makes little
sense to restrain one's use of them to a fraction of the capabilities,
except as an intellectual exercise.
For data, sure. (It's amazing how big even images can become, as the
resolution is increased. And that's not even video!)
For code, however, there are very good reasons to think that 'more is _NOT_
better'. More code means more complexity, and that has a host of Really Bad
consequences: harder to understand, more likely to have bugs, etc, etc.
It also often means that unless you have the Latest and Greatest hardware,
the machine is simply too slow to run the latest bloatware. The machine I'm
typing this on has a 1.4GHz single-core CPU, and _most_ things run on it just
fine - but going to many Web sites is now painful, since the 'obligatory'
HTTPS (another hot button, one I'll refrain from hitting right now, to keep
the length of this down) makes even simple Web operations slow.
Noel
1 Jan
1 Jan
9:26 a.m.
One other thing that larger/faster becomes a problem. That is probability!
We think of computers always making discrete steps. This is not always true. The
processors run so fast that different areas, even using the same clock, have enough skew
that the data has to be treated as asynchronous. Transferring asynchronous information it
always a probability issue. It used to be that 1 part in 2^30 was such a large number, it
could be ignored.
Parts often use ECC to account for this but that just works if the lost is recoverable (
not always so ).
Even the flipflops have a probability of loosing their value. Flops that are expected to
be required to hold state for a long time are designed differently that flops that are
only used for transient data.
All these probabilities add up. We are expecting more and more that no mistake will happen
when we add more and more data and code to deal with it. What fail safes do we have when
things are so complex that multiple failures are expected to happen.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Noel Chiappa via cctalk
<cctalk at classiccmp.org>
Sent: Monday, January 1, 2018 5:15:15 AM
To: cctalk at classiccmp.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: Computing from 1976
From: Peter Corlett
since we have computers with multiple gigabytes of
RAM, it makes little
sense to restrain one's use of them to a fraction of the capabilities,
except as an intellectual exercise.
For data, sure. (It's amazing how big even images can become, as the
resolution is increased. And that's not even video!)
For code, however, there are very good reasons to think that 'more is _NOT_
better'. More code means more complexity, and that has a host of Really Bad
consequences: harder to understand, more likely to have bugs, etc, etc.
It also often means that unless you have the Latest and Greatest hardware,
the machine is simply too slow to run the latest bloatware. The machine I'm
typing this on has a 1.4GHz single-core CPU, and _most_ things run on it just
fine - but going to many Web sites is now painful, since the 'obligatory'
HTTPS (another hot button, one I'll refrain from hitting right now, to keep
the length of this down) makes even simple Web operations slow.
Noel
10:17 a.m.
On 01/01/2018 11:26 AM, dwight via cctalk wrote:
One other thing that larger/faster becomes a problem.
That is probability!
We think of computers always making discrete steps. This is not always true. The
processors run so fast that different areas, even using the same clock, have enough skew
that the data has to be treated as asynchronous. Transferring asynchronous information it
always a probability issue. It used to be that 1 part in 2^30 was such a large number, it
could be ignored.
Well, very few (like NONE) mainstream chips are globally
asynchronous. (Systems often are, but the CHIPS,
themselves, are almost always fully synchronous.) The main
reason for this is the simulation software has not been
BUILT to handle that. A guy I work with is a partner in a
company working on simulation tools for GALS designs
(Globally Asynchronous, Locally Synchronous) which is a
fairly hot area of research now. And, not, there are
designs for synchronizers that reduce the probability issue
to FF metastability. Xilinx did some extensive work many
years ago on reducing FF metastability, and showed that with
dual-ranked FFs, the sun will burn out before you get an
incorrect event through the 2nd FF.
The Macromodule project at Washington University developed
this synchronization scheme and did a whole lot of
theoretical work on how to make it reliable and provable.
That is the basis for much of the GALS concepts.
Jon
noon
On Jan 1, 2018, at 12:26 PM, dwight via cctalk
<cctalk at classiccmp.org> wrote:
One other thing that larger/faster becomes a problem. That is probability!
We think of computers always making discrete steps. This is not always true. The
processors run so fast that different areas, even using the same clock, have enough skew
that the data has to be treated as asynchronous. Transferring asynchronous information it
always a probability issue. It used to be that 1 part in 2^30 was such a large number, it
could be ignored.
Parts often use ECC to account for this but that just works if the lost is recoverable (
not always so ).
That doesn't sound quite right.
"Asychronous" does not mean the clock is skewed, it means the system operates
without a clock -- instead relying either on worst case delays or on explicit completion
signals. That used to be done at times. The Unibus is a classis example of an
asynchronous bus, and I suppose there are others from that era. The only asynchronous
computer I can think of is the Dutch ARRA 1, which is notorious for only ever executing
one significant program successfully for that reason. Its successor (ARRA 2) was a
conventional synchronous design.
About 15 years or so ago, an ASIC company attempted to build processors with an
asynchronous structure. That didn't work out, partly because the design tools
didn't exist. I think they ended up building packet switch chips instead.
Clock skew applies to synchronous devices (since "synchronous" means "it
has a clock"). It is a real issue in any fast computer, going back at least as far
as the CDC 6600. The way it's handled is by analyzing worst case skew and designing
the logic for correct operation in that case. (Or, in the case of the 6600, by tweaking
until the machine seems to work.) ECC isn't applicable; computer logic doesn't
use ECC, it doesn't really fit. ECC applies to memory, where it is used to handle the
fact that data is not stored with 100% reliability.
I suppose you can design logic with error correction in it, and indeed you will find this
in quantum computers, but I haven't heard of it being done in conventional computers.
Even the flipflops have a probability of loosing their
value. Flops that are expected to be required to hold state for a long time are designed
differently that flops that are only used for transient data.
Could you give an example of that, i.e., the circuit design and where it is used? I have
never heard of such a thing and find it rather surprising.
paul
12:29 p.m.
On 01/01/2018 12:00 PM, Paul Koning via cctalk wrote:
"Asychronous" does not mean the clock is
skewed, it means the system operates without a clock -- instead relying either on worst
case delays or on explicit completion signals. That used to be done at times. The Unibus
is a classis example of an asynchronous bus, and I suppose there are others from that era.
The only asynchronous computer I can think of is the Dutch ARRA 1, which is notorious for
only ever executing one significant program successfully for that reason. Its successor
(ARRA 2) was a conventional synchronous design.
I'm not certain, but I believe that the Philco System 2000 had parts of
the CPU that operated asynchronously. At least that's what my failing
wetware seems to indicate.
--Chuck
11:48 a.m.
On 01/01/2018 05:15 AM, Noel Chiappa via cctalk wrote:
....The machine I'm
typing this on has a 1.4GHz single-core CPU, and _most_ things run on it just
fine - but going to many Web sites is now painful, since the 'obligatory'
HTTPS (another hot button, one I'll refrain from hitting right now, to keep
the length of this down) makes even simple Web operations slow.
Noel
I find that the boatloads of javascript are what bring my old machines
to their knees.? The initial https handshake really isn't *that* bad.
--Jason
12:08 p.m.
On 01/01/2018 11:48 AM, Jason Howe via cctalk wrote:
I find that the boatloads of javascript are what bring
my old machines
to their knees.? The initial https handshake really isn't *that* bad.
Heh, many of my device programming tools are *old* and require a PC with
real parallel port and/or serial ports. I suspect that there are modern
USB version, but why fool around with something that works?
My go-to-system for such things is an old socket A PC that has an Athlon
XP-M hacked into it running at about 2.3GHz. It's not awful on most
things, but web browsing is very sluggish--it never used to
be--something I attribute to more cruft-laden website code.
At any rate--I do my browsing on a contemporary system and ftp over any
file content needed. Works just fine.
--Chuck
2328
days inactive
2328
days old
6 comments
6 participants
participants (6)
-
cclist＠sydex.com -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
jason＠smbfc.net -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net