Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!sunic!dkuug!iesd!iesd.auc.dk!fischer From: fischer@iesd.auc.dk (Lars P. Fischer) Newsgroups: comp.sys.next Subject: Re: What NeXT *should* do next. Message-ID: Date: 24 Mar 90 04:11:47 GMT References: <1378@shelby.Stanford.EDU> <9967@batcomputer.tn.cornell.edu> <424@toaster.SFSU.EDU> Sender: news@iesd.auc.dk (UseNet News) Organization: Mathematics and Computer Science, University of Aalborg Lines: 31 In-reply-to: eps@toaster.SFSU.EDU's message of 24 Mar 90 02:04:16 GMT In article <424@toaster.SFSU.EDU> eps@toaster.SFSU.EDU (Eric P. Scott) writes: >Hey kids! RISC architecture may be faster on simple benchmarks, >but let's get realistic: it's a *memory hog*. Your performance >is going to suck without a lot more RAM than you're probably >willing to pay for, faster backing store than you can afford, >plus you're going to need more disk space for all your >executables, even with everything linked against shared >libraries. SPARC binaries are in general 25% larger than 68k (Sun-3) binaries. With RAM prices down to $200/4M, who cares? >RISCs are great for *dedicated* processors (like >file servers and network switches). They're a poor design choice >for general-purpose multiprogramming workstations like the NeXT, >and just plain unhappy in virtual memory environments. Did you ever use a RISC based workstation? If RISC is really a bad choice for a workstation, why then have all the major vendors introduced RISC workstations? Why do they consistently perform better? (no, I'm not talking benchmarks, I'm talking run time for compilers, LaTeX, etc, and simply the general feel of the thing). If you can point to any specific problem with RISC vs. multiprogramming or RISC vs. virtual memory, I'd be glad to hear about it. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.