eric@snark.uu.net (Eric S. Raymond) (02/27/89)
In article <745@tetons.uucp>, bb@tetons.UUCP (Bob Blau) writes: > This is the continuing saga of a startup company and its quest for > breakthroughs. [You are the president, etc.] > The first marketeer suggests, "We could be the first to sell a Vax > plug compatible system!" "Huh?" I say, "The VAX was a great machine for its day, sentimental favorite and all that, but its day is past -- that market's all going to supermicros as fast as they can get comptrollers to sign checks. You're fired!" > "No, no," another replies, "if you want to go after the fastest > growing market segment you should build a Crayette on a chip." "Hmm," say I, "Sexy idea but a loser in the long term. Cray's gonna get their lunch eaten by the graphics-supercomputer crowd as soon as that crew figures out how to plug cost-effectiveness, or maybe by the Japanese." > "You people don't know what big is," retorts a third marketeer. "If > you want a BIG installed base you should implement the 370/ESA > architecture on a chip." "Foo on that!", I reply. "Look what a beating the PCMs have been taking lately. Let them and IBM fight over a shrinking pie; I want an expanding one! You're fired, too!" > "Well," a fourth says definitively, "you could gain access to the > biggest market by far if you implement a 386, floating point unit, > super VGA controller, floppy and hard disk controller, and bus logic > on a chip." "Congratulations," I say "You've obviously been paying attention to reality. You're now the new VP for marketing." > The first engineer suggests "The best use of the extra area would be > to put in really large caches." "I can dig it," I say. "We do that, we can get better bang-per-buck out of our memory-procurement dollars." > "No, no," another replies, "a better use would be to implement lots > of parallel functional units to get the cycles per instruction (CPI) > below 1." "Who cares about CPI?" I snort. "The customers? Nah. Wake up and smell the coffee -- most current systems, especially UNIX boxes, are bottlenecked in I/O, not at the processor." > "Au contraire," shouts a third engineer, "the most efficient usage > would be to squeeze two RISC systems on the chip in a multiprocessing > configuration." "Forget it," I reply. "Packaging overhead isn't *that* high!" > "If you could do that," sneers a fourth, "then you'd be better off > halving the chip area and making cheaper RISC chips." "Right you are!" I said. "You and that first guy are now running the project. Go build me a dirt-cheap RISC uniprocessor with big caches." > The first scientist suggests, "Hey, you could implement a 64 bit > architecture, with 64 bit integers and 128 bit floating point > hardware!" "Right," I say, "and dominate the whole 2% of the computer market that cares about blindingly fast floating point. Get real!" > "No, no," the second replies, "a fast scalar RISC with an attached > vector unit on chip would be perfect." "Better, much better," I say. "Go talk to the engineers." > "Hogwash," the third scientist scoffs, "a VLIW on a chip would be a > screamin' demon." "Maybe," I say. "But I don't see VLIW as enough of a proven win over RISC to justify the development risk. Get back to me in three years." > "If you really want performance," the fourth proclaims, "you'd go to > massive parallelism, putting a 64 processor (with memory) connection > machine on a chip." "I don't care about parallelism," I say, "and neither does anyone else but petroleum geologists and weather forecasters and the rest of that floating- point crows, plus a couple academics. Get back to me in five years." > What will give the most performance? Most performance at what? > What will make the most money? A dirt-cheap, blazingly fast, UNIX-capable RISC micro. > What will be the most fun? Ditto. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718