🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13475

Re: Processing

#13475
From: ram
Date: Thu, 23 Apr 1987 17:27
91 lines
5872 bytes
As to "what are we going to do with all those cycles?", I find the "10 mips
is enough" arguments to be pretty unconvincing.

The "cycles don't limit X, we just don't know how to do X at all" argument
is somewhat flawed in that it ignores the possibility that there may be
fairly easy brute-force solutions that have been ignored due to
computational infeasibility.  It is true that such an algorithm, once
developed, could run slowly on generally avilable hardware, or less slowly
on today's supercomputers.  This argument ignores the problem of getting the
software developed in the first place.

Where are all the researchers who have unlimited supercomputer access to
develop these algorithms in real time?  Consider that the algorithms might
be initially developed in a form that is several orders of magnitude slower
than eventual usable versions.  This means that your researcher with his
personal supercomputer would still find development painfully slow.

Hans Moravec (who works on mobile robots at CMU) gave a talk in which he
argued fairly convincingly that massive cycles make lots of robotic problems
simpler. 

He had an interesting slide which plotted the log of data processing
capacity on the Y axis and the log of data storage capacity on the X axis.
He then plotted the capicities of various animals and computers.
Interestingly they all fell on about the same line, meaning that the ratio
of storage capicity to processing capacity is roughly constant and is
similar between computers and animals.  The bad news for A.I. and robotics
comes in when when you notice that a ~1mip computer is about equal to a
housefly...  I believe that the storage and processing capacity of a human
brain was estimated to be three orders of magnitude greater.

He also plotted in a linear time scale along the bottom.  He included data
points for electromechanical and mechanical data processing and calculating
machines, and showed that the exponential trend predated electronic
computers, going back before the turn of the century.

In order to deomstrate a way in which having lots of cycles could make life
easier, he discussed ways of representing a robot's "mental map" in some
detail.  These are data structures used to answer the question "Is there
anything there?" and "How can I get from here to there without running into
anything?".  Initial attempts used geometric models, representing objects as
polygons and paths as lines.  These methods weren't too successful because
they can't deal with uncertainlty very well; the results of the robot's
sensors tend to have a great deal of uncertainty.

A more successful but computationally intensive method involves breaking
space up into a grid and representing the certainly of an object being in
each location.  This representation is very good at dealing with sources of
uncertainty since you can combine the results of various inputs at each
location and can also apply transformations to smear out the probabilities
to represent things such as uncertainty in how much you have moved.

A successful path plotting algorithm is based on this representation.  It
basically looks for the "water running downhill" path, if the certainty
of an obstruction is considered to be height.

This algorithm also seems to be "embarrassingly parallel", which is a good
thing since we probably will running into diminishing returns on
uniprocessors pretty soon.

Comparisons with automobiles (the classical mature technology) are spurious.
In fact it seems that automobiles are a qualitatively different kind of
technology.  In the entire course of aotomobile development we have only
seen one or two orders of magnitude improvement.  I can think of a few
essential differences:
 -- Physical limits.  The 60,000 mph automobile simply isn't possible.  If
    you made one, it wouldn't be an automobile at all, it would be a 
    spacecraft, which brings us to:
 -- Definition.  The concept of an automobile is much less flexible than
    that of a computer.  An automobile is defined by its design (ground 
    vehicle with ~4 wheels that carries a few passengers) rather than 
    what it does (human transportation).  In contrast, almost any
    information processing device is called a computer.  Some of the 
    parallel architectures being considered seem more different from an IBM
    PC than a 747 is from a VW.  [500 people at 700 mph is 350,000
    person-miles per hour, as opposed to perhaps 240 for a VW.]
 -- External limitations, in particular scale.  An automobile is required to
    carry people, and they are rather inflexible.  If transportaion
    designers could minaturize people and their environment, redesigning
    them to run in liquid helium, then much more impressive improvements in
    transportation might be attainable.

The use of "speed" to refer to information processing capacity also
introduces a compelling but largely spurious analogy with automobiles.  A
faster automobile is harder to use and only gets you there faster.  In
contrast, a faster computer probably won't respond to interactions any
faster; instead it will be easier to use and will let you do things that
simply weren't feasible before.

  Rob
Technical Details
Message-ID: <8@wb1.cs.cmu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!wb1.cs.cmu.edu!ram
References: <505@sw1e.UUCP> <110@hippo.UUCP> <6123@bu-cs.BU.EDU> <6654@bu-cs.BU.EDU> <113@umich.UUCP> <6872@bu-cs.BU.EDU>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!wb1.cs.cmu.edu!ram
From: ram@wb1.cs.cmu.edu.UUCP
Newsgroups: comp.arch
Subject: Re: Processing
Message-ID: <8@wb1.cs.cmu.edu>
Date: Thu, 23-Apr-87 12:27:56 EST
Article-I.D.: wb1.8
Posted: Thu Apr 23 12:27:56 1987
Date-Received: Sat, 25-Apr-87 05:42:24 EST
References: <505@sw1e.UUCP> <110@hippo.UUCP> <6123@bu-cs.BU.EDU> <6654@bu-cs.BU.EDU> <113@umich.UUCP> <6872@bu-cs.BU.EDU>
Organization: Carnegie-Mellon University, CS/RI
Lines: 91