Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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 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