karl@sugar.uu.net (Karl Lehenbauer) (02/20/89)
In article <5900004@hpfcdc.HP.COM>, marc@hpfcdc.HP.COM (Marc 'Sphere' Sabatella) writes: > There was a discussion (wasn't it here?) a while ago concerning single > character I/O. NOS doesn't support it, and that fact alone causes it to > run X% faster than Unix on the same machine. I would also claim that the > better support for batch-mode processing in NOS also makes it faster than > Unix, ... (Yes, and I had been meaning to comment during that discussion and never got around to it.) While fighter planes are optimized for performance, they are missing many amenities like bathrooms, movies and in-flight meal and beverage service. If you want to go as fast as possible, you have to give up amenities. If one had to spend eight hours a day, five days a week (or more) traveling in an airplane, one might quickly come to desire almost anything over an F-16. These arguments, in fact, have been used in support of batch processing against timesharing since the invention of timesharing in the 1960s, and in support of assembly language programming over high-level language programming since the 1950s. I leave it to the reader to contrast how the vast majority of people interact with computers today, and how most programmers program, with these attitudes. > ...and > the numerous kludges necessary to get Unix to run on a machine with 60 bit > words is also bound to slow it down a little more, etc. 64-bit words. 60-bit, ones-complement, 6600 emulation is thoughtfully provided for sites for whom converting their software is an overwhelming task. For example, every PLATO site in the universe. >If you are going to shell out the major $$$ for a Cyber 200, ETA-20, or Cray 2, >you don't want to saddle it with an operating system that is not going to take >full advantage of the hardware. ...depends on what I want to do. Since most sites spend as much money on software as on hardware, maybe I'll run a little slower but save a lot of money on software, training, etc. I have a theory that for a lot of sites, mainframes are not a win. Consider that if you're sharing a mainframe among too many people, you may not be getting as many CPU cycles overall as you would if you had your own workstation. (The mainframe guy willing to come in at midnight gets a lot of cycles, though.) So it comes to a question of how many cycles are you getting, are you getting enough (never), and what can you do with them. I contend that, although it is possible to get a lot of cycles from a mainframe, you don't always, and when you do, you can't always use them in the ways you intend, as shown by the fact that you can't do character-at-a-time I/O under a lot of mainframe OSes, and mainframes have rotten timesharing environments in general. Another thing, mainframes are harder to program. At least, historically, user- friendly software came from minis and PCs. And finally, there is *the challenge* to mainframes. How much (in scalar MIPS) faster is a Cyber 20x than a fast MIPS M2000 like the DECstation 3100? Just a few times, right, like less than ten? A Cyber costs several dozen times more, right? (Granted, I/O and vector MFLOPS are another consideration, although there are some promising chip developments in this area, too, such as smart boards and fast buses for the former and the Intel N10 and Weitek chips for the latter.) I'd rather have 15 MIPS waiting on my 'enter' key (and doing other stuff, of course) than submit a batch job for 1/20th of 100 MIPS, not to say *some* people don't need them, just that a great many do not. I'm not a luddite or anything, though, which is to say that I would not mind having 100 MIPS waiting on my 'enter' key ;-) -- -- uunet!sugar!karl | "Everyone has a purpose in life. Perhaps yours is -- karl@sugar.uu.net | watching television." -- David Letterman -- Usenet BBS (713) 438-5018
gould@pilot.njin.net (Brian Jay Gould) (02/21/89)
In article <3472@sugar.uu.net>, karl@sugar.uu.net (Karl Lehenbauer) writes: > > While fighter planes are optimized for performance, they are missing many > amenities like bathrooms, movies and in-flight meal and beverage service. > If you want to go as fast as possible, you have to give up amenities. If one > had to spend eight hours a day, five days a week (or more) traveling in an > airplane, one might quickly come to desire almost anything over an F-16. > At this point of your text, I agree with where you were going. It is exactly right that people will select a system architecture and operating system to fill a particular need. I also agree that in most cases, the CPU should be wasted rather than the more costly programmer or user. Then you go on to: > > And finally, there is *the challenge* to mainframes. How much (in scalar MIPS) > faster is a Cyber 20x than a fast MIPS M2000 like the DECstation 3100? Just a > few times, right, like less than ten? A Cyber costs several dozen times more, Well, here you go off the deep-end. Supercomputers are very different from other systems, not just because they use vector processing, but because the performance of the program to the USER is much more important than the cost of the programmer. In engineering and scientific applications that require a supercomputer, the breakthroughs (or lack of) generated by computational science outweigh the cost of the supercomputer, software, and support staff by an order of magnitude. The cycles are the only thing that becomes important, and in many cases faster supercomputers aren't available. In any case, the cost of having a programmer live with COS, or VSOS is far lower than the cost of upgrading a system to handle the 20% cycle loss from UNICOS (much worse from ETA UNIX). Yes, I see a contradiction here. If the cycles are so important, why not get more supercomputers? The real reason has to do with normal corporate and government politics. Management often doesn't agree with my argument about the cycles being all important, but the user and support staff do. In the ideal world, everyone has enough cycles. In a better-than-this world the users have enough cycles. In a terrible world, the programmers have more cycles than the users. --> Any disclaimers, made by me or by anyone on my behalf, may or may not accurately represent my representation of myself or others. -- ------------------------------------------------------------------------- - Brian Jay Gould :: INTERNET gould@jvnca.csc.org BITNET gould@jvncc - - UUCP rutgers!njin!gould Telephone (201) 329-9616 - ------------------------------------------------------------------------s
seanf@sco.COM (Sean Fagan) (02/21/89)
In article <3472@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >In article <5900004@hpfcdc.HP.COM>, marc@hpfcdc.HP.COM (Marc 'Sphere' Sabatella) writes: >> ...and >> the numerous kludges necessary to get Unix to run on a machine with 60 bit >> words is also bound to slow it down a little more, etc. >64-bit words. 60-bit, ones-complement, 6600 emulation is thoughtfully >provided for sites for whom converting their software is an overwhelming >task. For example, every PLATO site in the universe. *sigh* 170-state machines have 60-bit words. 180-state machines, some of which can emulate 170-state machines, have 64-bit machines. The 170-state emulation by the 180-state machines is, by the way, 7600 + CMU (Character Move Unit), not 6600. And, joy of joys, 180-state is 2's complement, not 1. Frightening. >I have a theory that for a lot of sites, mainframes are not a win. Consider >that if you're sharing a mainframe among too many people, you may not be >getting as many CPU cycles overall as you would if you had your own workstation >(The mainframe guy willing to come in at midnight gets a lot of cycles, though) CPU cycles aren't everything, though. If it were, noone would be running UNIX, since it steals too many cycles away with all of its foolish context switches and multitasking. >So it comes to a question of how many cycles are you getting, are you getting >enough (never), and what can you do with them. I contend that, although it >is possible to get a lot of cycles from a mainframe, you don't always, and >when you do, you can't always use them in the ways you intend, as shown by >the fact that you can't do character-at-a-time I/O under a lot of mainframe >OSes, and mainframes have rotten timesharing environments in general. > >Another thing, mainframes are harder to program. At least, historically, user- >friendly software came from minis and PCs. Uhm, where did you get this idea? PLATO, which is very user-friendly, was written for Cybers, some of which, I will agree, are minis. >And finally, there is *the challenge* to mainframes. How much (in scalar MIPS) >faster is a Cyber 20x than a fast MIPS M2000 like the DECstation 3100? Just a >few times, right, like less than ten? A Cyber costs several dozen times more, >right? (Granted, I/O and vector MFLOPS are another consideration, although >there are some promising chip developments in this area, too, such as smart >boards and fast buses for the former and the Intel N10 and Weitek chips for >the latter.) I'd rather have 15 MIPS waiting on my 'enter' key (and doing other >stuff, of course) than submit a batch job for 1/20th of 100 MIPS, not to say >*some* people don't need them, just that a great many do not. A Cyber 170/760 will, for the most part, out perform most applications under Unix on a VAX, any model. Why? Because of the I/O. It doesn't have vectors, and only gets 10MIPS/MFLOPS. However, when you work in the *throughput* it gets, it becomes a *very* large win. Also, since you don't mind having a 15MIPS machine waiting for you enter key, how are you going to feel when, if you have a uucp connection, or an ethernet connection, it starts to slow down to an effective 8 MIPS or so during large transfers? How do you feel about the 15MIPS being idle most of the time? I can buy a DEC MIPS 3100 machine for about 12k. This will get me something like 10 MIPS or so. I can also get a CDC Cyber 180/830 for 100k. This will get me something like 3 MIPS or so. (Neither price represents any sort of discount). If I'm in any sort of business, the Cyber is going to be a better buy, since I can put 20 people on it without slowing down much. The DEC machine will become unacceptably slow if I put 20 people on it, all doing FORTRAN compiles. Or, I suppose, I could buy 20 DEC's, for a total of something like 240k. Even with just one user, I'll still lay odds that the Cyber (running NOS or NOS/VE) will be able to compile SPICE faster than the DEC machine. >I'm not a luddite or anything, though, which is to say that I would not mind >having 100 MIPS waiting on my 'enter' key ;-) So you enjoy paying extra thousands of dollars for something you don't use, right? People who buy Cray's, Cyber 205's, and ETA's *don't*, and there are times when they need every CPU cycle they can get, for upwards of 10-30 large, intensive applications. Don't run it under Unix (well, on an ETA, you might get a shot of some real speed, especially if they ever port Mach to the blasted thing). I wouldn't even suggest running it under NOS/VE. For a personal computer, Unix (and single-character I/O) is fine. For a mini, its debatable (Unix is ok, there, but I'd rather let some board handle the I/O than interrupt the CPU), and for mainframes and supers, try some other approach first. -- Sean Eric Fagan | "What the caterpillar calls the end of the world, seanf@sco.UUCP | the master calls a butterfly." -- Richard Bach (408) 458-1422 | Any opinions expressed are my own, not my employers'.
raveling@vaxb.isi.edu (Paul Raveling) (02/22/89)
In article <3472@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: > >If you want to go as fast as possible, you have to give up amenities. But if you want to approach, but perhaps not reach, going as fast as possible, it's sometimes possible to do this and to have better amenities. Borrowing the fighter analogy, a good example was introduction of the Douglas DC-2/DC-3, which was faster than many of the "pursuit" aircraft of its day but carried passengers with more comfort than the transports of its day. Consider that aviation was about 30 years old when it gave rise to DC-2 technology; computing was about the same when UNIX arose. Would we be happy flying DC-2's today, when modern airliners are 3 times faster and still more comfortable? [Well, at least they COULD put comfortable seats in them.] Or in the words of someone else here, "Why is this workstation running UNIX so much slower than my PC running DOS when I'm doing the same simple things?" [BTW, the workstation DID have faster hardware than the PC.] Or in my words: "Why can't I do on UNIX what we did on EPOS in 1975? And why is UNIX so much slower for the things it CAN do?" BTW, for the most part EPOS' capabilities were a superset of UNIX's -- It ran at least one UNIX application with little or no change. The one I'm aware of was icheck, which it adopted because a UNIX file system was one of the three types that EPOS supported simultaneously. This isn't a plug for EPOS -- it's a dead system, and it certainly wasn't perfect. But we could take a lesson from aerospace and be more open to non-UNIX OS architectures for the sake of both capability and speed. ---------------- Paul Raveling Raveling@isi.edu