tarvaine@tukki.jyu.fi (Tapani Tarvainen) (05/12/89)
In article <922@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) says: # on the few 68030 machines around (Next, Macs, Suns), it seems that one # statement I have read (68030 == 68020+10/15%) is quite reasonable In article <8081@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >Figures I've seen indicate about a 20-30% improvement. The Dhrystone test in our HP9000/340s (68030 at 16MHz) runs almost exactly 50% faster than in 319s (68020 also at 16MHz). Of course the Dhrystone measures only integer processing speed of the cpu, but nonetheless if you get only 10-15% speedup I suspect the bottleneck isn't the cpu. -- Tapani Tarvainen BitNet: tarvainen@finjyu Internet: tarvainen@jylk.jyu.fi -- OR -- tarvaine@tukki.jyu.fi
peter@ficc.uu.net (Peter da Silva) (05/13/89)
One thing you have to keep in mind in the 80386 versus 68030 debate is that, yes, there are fewer 68030 systems out there then 80386 boxes... but the vast majority of the 80386 systems are crippled by the poor performance of the AT bus. I have been benchmarking a 25 MHz 386 against our 16 Mhz 80286es on multibus. The speed advantage of the 80386 is almost entirely lost in the low performance of the bus. In fact many of our development tools run faster on the 286 or on a 386 in 286 mode on the multibus. If you just compare the market share of high-performance 80386 versus 68030 boxes the balance swings way back the other way. And once you leave behind AT-bus compatibility and cheap AT peripherals there's no reason to stick to the 80386. Either RISC, or if you're conservative the motorola chips, are far better. At least motorola doesn't have a history of abandoning their entire architecture every time they come out with a new chip. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
davidsen@sungod.steinmetz (William Davidsen) (05/15/89)
In article <4175@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | One thing you have to keep in mind in the 80386 versus 68030 debate is | that, yes, there are fewer 68030 systems out there then 80386 boxes... | but the vast majority of the 80386 systems are crippled by the poor | performance of the AT bus. I have been benchmarking a 25 MHz 386 against | our 16 Mhz 80286es on multibus. The speed advantage of the 80386 is | almost entirely lost in the low performance of the bus. In fact many | of our development tools run faster on the 286 or on a 386 in 286 mode | on the multibus. You don't seem to mention what o/s you're using to determine this. Given any particular architecture, using a 16 bit o/s like MS-DOS, there will be very little performance diference between the 286 and 386. However, if the 386 code uses the full instruction set, it should run much faster than a 286 at the same speed, running the best 16 bit version of the same program. Of course there can be programs written to always use 16 bit data, so this is not an absolute. When I got my first 386 UNIX system I ran some programs compiled for 286 on the 386, under the 386 o/s. With no other change than recompilation most programs ran about 2:1 faster. These programs were mainly data compression programs (compress, zoo), and some text processing tools. Perhaps you could clarify conditions you are observing. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
peter@ficc.uu.net (Peter da Silva) (05/16/89)
In article <13804@steinmetz.ge.com>, davidsen@sungod.steinmetz (William Davidsen) writes: > In article <4175@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > | One thing you have to keep in mind in the 80386 versus 68030 debate is... > | the vast majority of the 80386 systems are crippled by the poor > | performance of the AT bus. ... In fact many > | of our development tools run faster on the 286 or on a 386 in 286 mode > | on the multibus. > You don't seem to mention what o/s you're using to determine this. Well, how many operating systems do you know of that run on the multibus and on the AT bus? UNIX (or variants) We're using Xenix System-III R3.5 on the 286 and Unix System V/386 R3.2 on the 386. Yes, the 386 runs benchmarks much faster. We're talking whole system performance here. It's like racing a Mustang against a Porsche. The Mustang pulls ahead in the straight but the Porsche with its little 6-cylinder engine catches up in the curves... because it has a better suspension. Again, the 386AT is great when you're CPU bound, but as soon as you hit the disk the 286multibus pulls ahead. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
pcg@aber-cs.UUCP (Piercarlo Grandi) (05/16/89)
In article <4175@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
One thing you have to keep in mind in the 80386 versus 68030 debate is
that, yes, there are fewer 68030 systems out there then 80386 boxes...
but the vast majority of the 80386 systems are crippled by the poor
performance of the AT bus. I have been benchmarking a 25 MHz 386 against
our 16 Mhz 80286es on multibus. The speed advantage of the 80386 is
almost entirely lost in the low performance of the bus. In fact many
of our development tools run faster on the 286 or on a 386 in 286 mode
on the multibus.
Well, the problem is not the AT bus, because virtually all 386 ATs use
caching and a private 32 bit bus for CPU-memory accesses. CPU bound programs
on such 386s as I have seen don't have a problem with the AT bus, because
they do not use it. On the other hand, the stock AT bus peripheral
controllers suck (euphemism), in particular the disc controller, that is
single threaded and has a transfer rate of about 160kbytes/sec. If you get
a good disc controller (e.g. a 1:1 RLL/ESDI, or even better a multithreading
fast SCSI one), things improve A LOT. The limit of the AT bus for
peripherals is about 1MByte second, e.g. about like the Unibus, and there
are few peripherals that can get up to that, in machines of that class.
And once you leave behind AT-bus compatibility and cheap AT peripherals
there's no reason to stick to the 80386. Either RISC, or if you're
conservative the motorola chips, are far better. At least motorola
doesn't have a history of abandoning their entire architecture every
time they come out with a new chip.
I cannot resist saying that given the premises, this really should be a plug
for the NS 32000 family, not the MC 68000 one. :-) :-).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpeter@ficc.uu.net (Peter da Silva) (05/18/89)
In article <954@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > Well, the problem is not the AT bus, because virtually all 386 ATs use > caching and a private 32 bit bus for CPU-memory accesses. CPU bound programs > on such 386s as I have seen don't have a problem with the AT bus, because > they do not use it. True, and known. But the problem is still the AT bus because, in general, the bottleneck on UNIX tends to be disk. The typical huge disk buffers help a lot, but it's still a problem. > I cannot resist saying that given the premises, this really should be a plug > for the NS 32000 family, not the MC 68000 one. :-) :-). Probably. I've never had the opportunity to use or even see a 32000-based machine, unfortunately. Is the problem market timing, the prestige of the people who started Sun, or what? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
daveh@cbmvax.UUCP (Dave Haynie) (05/19/89)
in article <13804@steinmetz.ge.com>, davidsen@sungod.steinmetz (William Davidsen) says: > Given any particular architecture, using a 16 bit o/s like MS-DOS, there > will be very little performance diference between the 286 and 386. In fact, some 286 instructions go faster on the 286 than the 386 pertending to be a 286. > However, if the 386 code uses the full instruction set, it should run > much faster than a 286 at the same speed, running the best 16 bit > version of the same program. Of course there can be programs written to > always use 16 bit data, so this is not an absolute. Well, certainly, if you've got something that needs lots of data memory, like Compress, you're goofy to run this on a '286 machine, with all those silly "far" pointer routines. Can't help but go faster when it's recompiled for any 32 bit machine. Conversely, little tiny programs (eg, Benchmarks) can find themselves sitting completely in an external 32k cache such as one finds on many high end '386 machines. One may find these programs run much faster launched from MS-DOS, and thus owning the machine, than were they run under UNIX, where a task swap may come along and dump the cache.... > bill davidsen (davidsen@crdos1.crd.GE.COM) -- 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
daveh@cbmvax.UUCP (Dave Haynie) (05/19/89)
in article <4229@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) says: > Probably. I've never had the opportunity to use or even see a 32000-based > machine, unfortunately. Is the problem market timing, the prestige of the > people who started Sun, or what? I think the problem was the first 32ks (actually called 16ks until some deal set up with TI made National change the name to 32k) were kinda wimpy as compared to the existing 680x0s at the time. I looked at them briefly, way back when, but I don't recall whether it was the performance at a given clock speed or the lack of high enough clock speeds. The nicest part of the first 32ks was the instruction set, which was the same across all parts, like the 68000, only more so, and more orthogonal. In time, the 32ks appear to have caught up and surpassed the 80x86 and 680x0 families (at least, the 32532 looks better on paper than a 68030, I haven't built a 32532 system to compare with the 68030 or anything...), but everyone looking for that kind of chip is already committed to Moto or Intel. National's recently taken to building specialized version of the 32k line. They have a 16 bit CPU with some added graphics functions, and they recently announced a version of the 32532 with the MMU yanked out, also targeted toward graphics applications (laser printer comes to mind). > Peter da Silva, Xenix Support, Ferranti International Controls Corporation. > > Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. > Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. -- 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
henry@utzoo.uucp (Henry Spencer) (05/19/89)
In article <6924@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >> Probably. I've never had the opportunity to use or even see a 32000-based >> machine, unfortunately. Is the problem market timing, the prestige of the >> people who started Sun, or what? > >I think the problem was the first 32ks ... were kinda wimpy as >compared to the existing 680x0s at the time... The problem was not so much wimpiness, as the state of the bug list. Ugh. Choke. Barf. The first 32ks looked okay on paper but were a disaster area in silicon. And National took so long fixing them that almost everybody lost interest. At the beginning they were a bit behind, but had a fair chance to pick up a significant share of the market if they'd had clean silicon. They, uh, didn't. I'm told that they have cleaned up their act quite a bit since, but that early stumble was so severe that it hasn't done them a lot of good. -- Subversion, n: a superset | Henry Spencer at U of Toronto Zoology of a subset. --J.J. Horning | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
seanf@sco.COM (Sean Fagan) (05/22/89)
In article <6924@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <4229@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) says: >> Probably. I've never had the opportunity to use or even see a 32000-based >> machine, unfortunately. I have. Real fun to play with. Problems described below. >I think the problem was the first 32ks (actually called 16ks until some deal >set up with TI made National change the name to 32k) were kinda wimpy as >compared to the existing 680x0s at the time. I looked at them briefly, >way back when, but I don't recall whether it was the performance at a >given clock speed or the lack of high enough clock speeds. The nicest >part of the first 32ks was the instruction set, which was the same across >all parts, like the 68000, only more so, and more orthogonal. I think the real problem was that it took NS *many* revisions to get a working CPU. The system I mentioned up above was a 16032, Revision R, running at 6 MHz (*slow*). (Note: it was still about half as fast as our 3b5, but, then, the 3b5 didn't have paging.) Despite being the 18th or so revision of the CPU, there were still quite a few bugs associated with it and the MMU (seperate chip). In fact, the Unix kernel we had (4.1BSD based) had code in it that would determine whether the mmu was bad, and, if so, not use the "features" that caused it to manifest. Also, if I remember correctly, the compiler wouldn't generate a certain addressing mode (double indirect something, I think; the "most complicated" mode on it) because it was known to be buggy. Oh, and a friend says that the ENTRY instruction is wrong; something about it pushing the frame pointer at the wrong time (if what he says is true, then I can believe it). Unfortunately, this was a "feature," documented and everything, so it still exists in the '532. I *really* like the series. Nice instruction set (even if it wasn't designed by Seymour Cray 8-)), well integrated sub-processors (FPU, MMU, etc.), nice addressing modes, etc. When NS got the CPU's working, I was expecting them to take off, but, apparantly, Motorola beat them to the punch. Too bad. (Also, I would like to note that NS is, as far as I know, the only processor maker who managed to ship their *co*processors bug-free before the processor did. IBM, for example, use the NS fpu in the RT for a while.) Remember, I have *no* personal affiliation with *any* chip maker, and I don't mean to slight National Semiconductor. I like their stuff, and I am (still) trying to get a cheap ICM for myself. -- Sean Eric Fagan | "[Space] is not for the timid." seanf@sco.UUCP | -- Q (John deLancie), "Star Trek: TNG" (408) 458-1422 | Any opinions expressed are my own, not my employers'.
amos@taux01.UUCP (Amos Shapir) (05/22/89)
In article <2760@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >I think the real problem was that it took NS *many* revisions to get a >working CPU. The system I mentioned up above was a 16032, Revision R, >running at 6 MHz (*slow*). Just to set the record straight, the last two CPU's in this series (NS32332 and NS32532) ran a full implementation of UNIX on rev A of the chip. Marketing were so cautious by this time that the 32332 was not even announced until we had a working silicon. The only way to get rid of past follies seems to be changing the name of the company, but we have a reputation to keep... :-) -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)