kirkaas@oahu.cs.ucla.edu (paul kirkaas) (11/28/88)
First the disclaimers: I know this sort of question is meaningless as it stands and depends on all sorts of factors like the application, the program, prejudice, etc.; & I'm sure this has been covered before -- but I haven't seen it. So, as regards the 80386/68030 -- Which is better? Which is faster? Why? I'm really thinking about the NeXT vs. an 80386 based Unix machine. Paul Kirkaas kirkaas@cs.ucla.edu
cjosta@taux01.UUCP (Jonathan Sweedler) (11/28/88)
In article <18266@shemp.CS.UCLA.EDU> kirkaas@cs.ucla.edu (paul kirkaas) writes: |So, as regards to the 80386/68030 -- Which is better? Which is faster? The 32532... :-) -- Jonathan Sweedler === National Semiconductor Israel UUCP: ...!{amdahl,hplabs,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com
daveh@cbmvax.UUCP (Dave Haynie) (12/01/88)
in article <18266@shemp.CS.UCLA.EDU>, kirkaas@oahu.cs.ucla.edu (paul kirkaas) says: > Summary: Which is better? > So, as regards the 80386/68030 -- Which is better? Which is faster? > Why? Going all out, I'd expect a 68020 to be slower than an 80386 system, a 68030 to be faster. The '030 gets a nice boost from internal instruction and data caches and internal split I and D buses. To go full speed, though, an '030 will require faster memory than an 80386 running at the same clock speed, since the '386 with it's pipelining mechanism allows full speed operation most of the time with slower memory. Also, 33MHz versions of the '030 are shipping, while the fastest available '386 is the 25MHz part. > I'm really thinking about the NeXT vs. an 80386 based Unix machine. That's an entirely another question. Market competition in the PClone area has resulted in a whole slew of really good '386 systems, with large external static caches and other performance enhancements. The NeXT machine, according to all the stuff I've read at least, is only a moderate performance 25MHz 68030 system. For instance, the '030 in the NeXT system requires 9 clocks to prefetch a cache line of 4 longwords; the 68030 is capable of doing that in 5 clocks given the proper memory system. On the other hand, the 68030 memory management is supposedly a better match to UNIX than that of the 80386. An intersting test case of this very question is coming up. Sun is supposed to be about ready with a series of '030 based workstations, I guess pretty much an upgrade of the Sun 3 series. Comparing the UNIX performance of one of these to the Sun 386i should be about as equal a test as you can devise. > Paul Kirkaas > kirkaas@cs.ucla.edu -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
mike@stolaf.UUCP (Mike Haertel) (12/05/88)
In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Going all out, I'd expect a 68020 to be slower than an 80386 system, a >68030 to be faster. I disagree. Working for the GNU project this summer I had an opportunity to use various 386 and '020 machines and, taking differences of clock speed, etc. into account I had the impression that the '020 machines were faster. I was using the same compiler (gcc) on both architectures. I believe the main reason the '020 won was simply that it had more registers available for temporary values for the optimizer. Eight registers (as in the 386) is clearly insufficient, and in fact 16 (as in the '020) is probably not enough. Maybe 32 would be right? #if hearsay_evidence_were_admissible_in_court I vaguely recall hearing of some PC type magazine (not Byte, which always says the 386 is faster, but maybe Dr. Dobbs?) running various benchmarks and, however reluctantly, concluding that the '020 was faster. Disclaimer: I personally have read no such article, someone just told me about it. I don't remember who either. #endif -- Mike Haertel mike@wheaties.ai.mit.edu In Hell they run VMS.
rajeevc@mipos2.intel.com (Rajeev Chandrasekhar) (12/05/88)
In article <18266@shemp.CS.UCLA.EDU> kirkaas@cs.ucla.edu (paul kirkaas) writes: > > > >So, as regards the 80386/68030 -- Which is better? Which is faster? The 80386 is better ... :-) > >I'm really thinking about the NeXT vs. an 80386 based Unix machine. NeXT runs MACH which is more 4.xlike, with the 386 you can run the sysV/386 which is one of "Products of the year" (courtesy Unix World) I am not sure how compatible Mach is with Sys V, so you probably want to find that out .. #include <disclaimer.h> > > >Paul Kirkaas Rajeev Chandrasekhar Intel Corp >> theres someone in my head, and its not me << 2625, Walsh Ave MS SC4-59 (408) 765-4632 Santa Clara, CA 95051 {hplabs,oliveb}!intelca!mipos2!rajeevc
mcdonald@uxe.cso.uiuc.edu (12/05/88)
In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Going all out, I'd expect a 68020 to be slower than an 80386 system, a >68030 to be faster. Okay, I know that this has been said before. But I get so sick of this I'll say it again: Offhand, I expect that things other than the chip will be of more import comparing those three chips. Like compilers. Like memory organization. I haven't personally benchmarked any 680x0 systems other than Macs, which are by any measure slow. But based on my tests of 386 machines AND COMPILERS and published comparisons, I'd call it a dead heat. If you're going to compare compiled programs (as opposed to assembled) you should get a compiler for each system designed by people WHO HAVE A FINANCIAL INTEREST IN MAKING THEIR SYSTEM LOOK GOOD. Gnu C is not a fair test. (All this was done due to my suffering "workstation envy" until I got a 32 bit 80386 compiler. Total cure.) Sorry to fill up the august halls of comp.arch with such drivel.
daveh@cbmvax.UUCP (Dave Haynie) (12/06/88)
in article <788@stolaf.UUCP>, mike@stolaf.UUCP (Mike Haertel) says: > Keywords: 680x0 wins > In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Going all out, I'd expect a 68020 to be slower than an 80386 system, a >>68030 to be faster. > I disagree. Working for the GNU project this summer I had an opportunity > to use various 386 and '020 machines and, taking differences of clock > speed, etc. into account I had the impression that the '020 machines > were faster. One thing I wasn't think of is that many of the existing workstation level '020 machines have a faster MMU. Motorola's 68851 is nice from an MMU function point of view; it can do practically anything you can think of. But it always adds a wait state to a 68020 memory access. Perhaps some of the Sun MMUs deliver performance closer to that of the raw 68020. Of course, the other factor may be how well each architecture is matched to the OS it's running with. I based my guess above mainly on apparent hardware efficiencies. I've seen articles that put the '386 ahead of the '020, and others that switch that around. No matter what, it looks to be a pretty close call, and it's probably application dependent when it comes right down to it. > Mike Haertel mike@wheaties.ai.mit.edu > In Hell they run VMS. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
mac3n@babbage.acc.virginia.edu (Alex Colvin) (12/06/88)
> >So, as regards the 80386/68030 -- Which is better? Which is faster?
uh... You gotta say whether you want a 16, 20, or 25MHz 80386. How fast
is the memory system? cache?
Besides, what do you want it for, FLOPS or context switches/second (is
there a clever acronym for that?)?
The support hardware probably makes at least as much difference as the CPU.
Since most program(mer)s don't see it (directly), it's easy to forget.
$include(:inc:disclaimer.lit)bruce@blue.blue.gwd.tek.com (Bruce Robertson) (12/08/88)
> Motorola's 68851 is nice from an MMU > function point of view; it can do practically anything you can think of. > But it always adds a wait state to a 68020 memory access. At this point in time, it's more interesting to compare the 68030 and the '386. The 68020 can be classified as obsolete for UNIX applications, since the built-in MMU in the 68030 doesn't add ANY delay (except of course when doing table walks), and a 68020/68851 combination will always be more expensive than just a 68030. The 68020 is still useful for non-MMU applications. -- Bruce Robertson bruce@blue.gwd.tek.com -- -- Bruce Robertson bruce@blue.gwd.tek.com
sedwards@esunix.UUCP (Scott Edwards) (12/08/88)
In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Going all out, I'd expect a 68020 to be slower than an 80386 system, a >68030 to be faster. What does it matter? What if one is 25% faster than the other one? His program takes 5 seconds to run instead of 4? I'll bet that your average user (assuming there's only one user on the system) couldn't tell the difference if one CPU was 2X the other one. How many programs do you run on a personal computer that are CPU intensive? For example: I wrote a program to solve a problem by doing an exhaustive search on my pc at home (NS32016 @ 6Mhz), it took a little over 5 minutes to find the solution (about 30 minutes to write and debug). Just for curiosity (and a slack moment) I put the program on the Sun 3 at work the next day to see how much faster it could solve the problem, after fooling around for a while I got it down to about a minute and a half, but it took more time to write and debug. TOTAL time to get a solution was less for a much slower CPU! I would decide based on factors like: what am I going to do with it, what kind of programs are you going to run on it, are you going to write your own or buy them, how much are they going to cost? I've also found that faster disks, make a BIG difference in performance when you are doing things like program development. From article <788@stolaf.UUCP>, by mike@stolaf.UUCP (Mike Haertel): > In Hell they run VMS. Hmmm. Last time I was there they were using UNIX :-). -- Scott
elg@killer.DALLAS.TX.US (Eric Green) (12/09/88)
in article <3283@mipos3.intel.com>, rajeevc@mipos2.intel.com (Rajeev Chandrasekhar) says: > In article <18266@shemp.CS.UCLA.EDU> kirkaas@cs.ucla.edu (paul kirkaas) writes: >>I'm really thinking about the NeXT vs. an 80386 based Unix machine. > NeXT runs MACH which is more 4.xlike, with the 386 you can run > the sysV/386 which is one of "Products of the year" (courtesy Unix World) > I am not sure how compatible Mach is with Sys V, so you probably want to > find that out .. Sys V sux. I'm typing this from a 3b2 running Sys V.3 (the latest/greatest), and while it may have some nice underpinnings (streams and everything), it's currently missing some of the best-loved pieces of BSD4.x -- e.g. I can't type "what" or "finger" or "talk" or "uptime" or .... not to mention that it totally lacks job control signals, so that if I run something like, say, "shl" to get the same functionality, my editors don't know they've been suspended/resumed and thus can't redraw the screen automagically for me. Not to mention that half of Sys V doesn't understand the pseudo-ttys that "shl" uses, e.g. good old "write", primitive as it is, barfs and aborts when I try to run it under "shl". "Product of the Year" for Bell Technologies Sys V/386 simply signifies that people are desperate to have Unix, any Unix, on their 386-based microcomputers, and BSD4.x isn't easily commercially available (need a lot of resources to port it to new architectures, because so much of it assumes VAX, and it needs a lot of memory and disk space because, well, must admit it's a bit of a hog). Re: 68030 vs. 80386 -- what I'd love to see on the '386 would be a Multics-like system. The hardware looks so Multics-like... seems a shame to stuff Unix onto it, Unix which was designed for linear address spaces, PDP-11s and Vaxen.... Unix in a single segment isn't exactly taking advantage of the '386's best parts. Unix and the 68030, on the other hand, were practically made for each other.... -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "We have treatments for disturbed persons, Nicholas. But, at least for the moment, we have no treatment for disturbing persons." -- Dr. Island
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (12/10/88)
In article <6360@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: | Re: 68030 vs. 80386 -- what I'd love to see on the '386 would be a | Multics-like system. The hardware looks so Multics-like... seems a | shame to stuff Unix onto it, Unix which was designed for linear | address spaces, PDP-11s and Vaxen.... Unix in a single segment isn't | exactly taking advantage of the '386's best parts. Unix and the 68030, | on the other hand, were practically made for each other.... I thought of Multics when I first saw the 386. Come on someone, Multics is certified B2 secure, and it's written in a high level language. Can't someone see the market for Multic/386? Could it really be harder to port than UNIX? If I could get Multics I think I'd go out and buy another 386 just to run it. I had a chance at a 645 (the original Multics machine) for the cost of the copper, but I didn't have a place to put it, and I couldn't afford a new house and a divorce at the same time ;-) -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dtynan@sultra.UUCP (Der Tynan) (12/10/88)
In article <1146@esunix.UUCP>, sedwards@esunix.UUCP (Scott Edwards) writes: > In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >Going all out, I'd expect a 68020 to be slower than an 80386 system, a > >68030 to be faster. > > What does it matter? What if one is 25% faster than the other one? > His program takes 5 seconds to run instead of 4? I'll bet that your > average user (assuming there's only one user on the system) couldn't > tell the difference if one CPU was 2X the other one. How many > programs do you run on a personal computer that are CPU intensive? > > -- Scott This is the greatest load of codswallop I've seen since IBM introduced the PC! I sure hope you have nothing to do with the design of future systems *I* might have to use. How many programs do *I* run that are compute-bound? *Tons* I'd run even more if I had the cycles. I can sure tell the difference between an eight-hour compile, and a four-hour compile. Can you? Ever tried doing a logic simulation? An auto-routed PC layout? A fast-fourier transform? A full-out kernel compilation? Disk speeds I can get around, with effective use of track-buffering, block cacheing or elevator algorithms. If the CPU don't go, it's a waste of time. Heck, a one-megabyte RAMDISK ain't that hard to put in place. Wanna swap your PC for my 4.77MHz clunker??? Too often, we generate this ideal of what the average user does with a machine. Sales forecasting is an exact science. When you're finished, it's exactly wrong :-) - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---
daveh@cbmvax.UUCP (Dave Haynie) (12/14/88)
in article <1146@esunix.UUCP>, sedwards@esunix.UUCP (Scott Edwards) says: > > In article <5375@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Going all out, I'd expect a 68020 to be slower than an 80386 system, a >>68030 to be faster. > What does it matter? What if one is 25% faster than the other one? > His program takes 5 seconds to run instead of 4? I'll bet that your > average user (assuming there's only one user on the system) couldn't > tell the difference if one CPU was 2X the other one. How many > programs do you run on a personal computer that are CPU intensive? It all depends on what your limiting factor is. A computer SYSTEM that's 2x faster than another is going to be noticable. > I've also found that faster disks, make a BIG difference in > performance when you are doing things like program development. Sure enough, I've notice the same thing. In fact, I very often use the fastest disk I can possibly get for development -- a RAM disk, at least during most of the compilation phases. Guess what, that RAM disk brings me back to CPU speed as the most critical factor in the system (the 18ms hard drive doesn't hurt, either). My posting was basically in response to the question of "who's faster", without really caring for the reason. And in many case, you can't do anything about it. Even if I found an 80386 or (more likely) some other chip that was faster than a 68030, I couldn't use it in the systems I design. Similarly, if you want to run MS-DOS or OS/2, a 68030 isn't going to do you much good. We did mention UNIX, which will run on just about anything, but in most case UNIX may not be your only, or even primary, concern. And of course, it's just basic human nature to want to be the fastest guy on the block. > From article <788@stolaf.UUCP>, by mike@stolaf.UUCP (Mike Haertel): >> In Hell they run VMS. > Hmmm. Last time I was there they were using UNIX :-). No. In Hell, they run MS-DOS. And you only get 256k. > -- Scott -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
aglew@mcdurb.Urbana.Gould.COM (12/16/88)
>Sure enough, I've notice the same thing. In fact, I very often use the >fastest disk I can possibly get for development -- a RAM disk, at least >during most of the compilation phases. Guess what, that RAM disk brings >me back to CPU speed as the most critical factor in the system (the 18ms >hard drive doesn't hurt, either). Not quite. The RAMdisk brings you back to memory system speed. Many modern CPUs are faster than their memory.
mark@UNIX386.Convergent.COM (Mark Nudelman) (12/17/88)
In article <6360@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: > Sys V sux. I'm typing this from a 3b2 running Sys V.3 (the > latest/greatest), and while it may have some nice underpinnings > (streams and everything), it's currently missing some of the > best-loved pieces of BSD4.x -- e.g. I can't type "what" or "finger" or > "talk" or "uptime" or .... That's funny... I'm running SVR3 and I can type "what" or "finger" or "talk" or "uptime". It says "what: not found", "finger: not found", .... :-) > not to mention that it totally lacks job > control signals, so that if I run something like, say, "shl" to get > the same functionality, my editors don't know they've been > suspended/resumed and thus can't redraw the screen automagically for > me. Not to mention that half of Sys V doesn't understand the > pseudo-ttys that "shl" uses, e.g. good old "write", primitive as it > is, barfs and aborts when I try to run it under "shl". I think job control is one of the most important features SysV is missing. At least it will be in SVR4. Too bad the rest of the BSD crud will be as well. :-( Mark Nudelman {sun,decwrl,ihnp4!hplabs}!pyramid!ctnews!UNIX386!mark I never said it.
lm@snafu.Sun.COM (Larry McVoy) (12/18/88)
In article <6360@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: > Sys V sux. I'm typing this from a 3b2 running Sys V.3 (the I'd have to disagree with that statement. I've worked on both Sys5 and BSD based boxes as a kernel hack for several years. The Vr3 kernel is fairly clean and easy to work with. I'd like to say the same for the BSD kernel but everyone would die laughing. Furthermore, from a user's viewpoint, if you add one of the (now) common TCP/IP packages to your SysV box, you end up with 99% of what you want. For my money, you can't beat a 386 box running sys5 + tcp/ip + X. Bang for the buck, that leaves everyone else in the dust. Larry McVoy (lm@sun.com) My opinions are that.
yap@hammer.me.toronto.edu () (12/20/88)
In article <213@UNIX386.Convergent.COM> mark@UNIX386.Convergent.COM (Mark Nudelman) writes: >In article <6360@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: >> Sys V sux. I'm typing this from a 3b2 running Sys V.3 (the Sad, but true. >I think job control is one of the most important features SysV is >missing. At least it will be in SVR4. > >Too bad the rest of the BSD crud will be as well. :-( You're joking. Right? Else, you've never had the PLEASURE of working with a NETWORK of bsd machines. Never experienced the freedom of being able to flit between machines and files systems, with no more bother than a keystroke or two. Never had the chance to ... ad infinitum. > >Mark Nudelman >{sun,decwrl,ihnp4!hplabs}!pyramid!ctnews!UNIX386!mark +------------------------------------+ | LIVE FREE OR DIE! | | | | BBBBBBB SSSSS DDDDDDD | | B B S S D D | | B B S D D | | BBBBBBB SS D D | | B B S D D | | B B S D D | | B B S S D D | | BBBBBBBB SSSSS DDDDDDD | | | | LIVE FREE OR DIE! | +------------------------------------+
peter@ficc.uu.net (Peter da Silva) (12/22/88)
In article <2014.1988Dec20.02:50:05@hammer.me.toronto.edu>, yap@hammer.me.toronto.edu writes: > You're joking. Right? Else, you've never had the PLEASURE of working with > a NETWORK of bsd machines. Never experienced the freedom of being able to > flit between machines and files systems, with no more bother than a keystroke > or two. Never had the chance to ... ad infinitum. Well, I'm using such a network right now. However, it's a network of System *III* machines, though we're going to be adding some SV boxes later on. BSD != Network. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.