jer@pender.ee.upenn.edu (Joel Ratsaby) (04/04/91)
I am planning to purchase a 386/33Mhz system, but I am still not sure whether to wait a little longer for the proces of 486 systems to drop. Can anyone point me to some discussions on the Net, or articles, comparing the EXTRAs that come with a 486 System. Also, regarding multitasking, is it only possible when running Windows, or does the new version of DOS (4.01) support multitasking. 10 Q --Joel ___ _ __ _ _ __ ( > // / ` // ' ) ) _/_ / __/______/> // /-- // o /--' __. / _ __. /___ , / / (_) (__</__ (___, </_<__ / \_(_/|_<__/_)_(_/|_/_) (_/___
c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) (04/04/91)
In article <40409@netnews.upenn.edu> jer@pender.ee.upenn.edu writes: >I am planning to purchase a 386/33Mhz system, but I am still not >sure whether to wait a little longer for the proces of 486 systems >to drop. Can anyone point me to some discussions on the Net, or >articles, comparing the EXTRAs that come with a 486 System. One of the more significant differences between the 486 and 386 is that the 486 has a built in math coprocessor. If you don't make use of the math coprocessor, IMHO a 386/33 system would be a better buy than a 486/33. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
andrewsh@lonex.radc.af.mil (Harold G. Andrews II) (04/04/91)
In article <1991Apr4.062503.1325@agate.berkeley.edu> c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) writes: >In article <40409@netnews.upenn.edu> jer@pender.ee.upenn.edu writes: >>I am planning to purchase a 386/33Mhz system, but I am still not >>sure whether to wait a little longer for the proces of 486 systems >>to drop. Can anyone point me to some discussions on the Net, or >>articles, comparing the EXTRAs that come with a 486 System. > >One of the more significant differences between the 486 and 386 >is that the 486 has a built in math coprocessor. If you don't make >use of the math coprocessor, IMHO a 386/33 system would be a better >buy than a 486/33. Yeah, but... The 486 also has an internal 8K cache which offers a substantial performace improvement over a 386 with an external cache. If you can get away with using the 386, then sure buy it. If you want more power, get the 486. -Andy ******************************************************************************* * Harold G. "Andy" Andrews II, 1Lt, USAF * "Many the man whose punctuality * * andrewsh@lonex.radc.af.mil * serves only to warm his chair." * * Rome Laboratory/IRRE * * * Griffiss AFB, NY 13441-5700 * - M. Kabrisky * * (315) 330-7788 (AVN Prfx 587) * (Not an official USAF viewpoint) * *******************************************************************************
c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) (04/05/91)
In article <1991Apr4.142742.20601@lonex.radc.af.mil> andrewsh@lonex.radc.af.mil (Harold G. Andrews II) writes: >In article <1991Apr4.062503.1325@agate.berkeley.edu> c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) writes: >>In article <40409@netnews.upenn.edu> jer@pender.ee.upenn.edu writes: >>>I am planning to purchase a 386/33Mhz system, but I am still not >>>sure whether to wait a little longer for the proces of 486 systems >>>to drop. Can anyone point me to some discussions on the Net, or >>>articles, comparing the EXTRAs that come with a 486 System. >>One of the more significant differences between the 486 and 386 >>is that the 486 has a built in math coprocessor. If you don't make >>use of the math coprocessor, IMHO a 386/33 system would be a better >>buy than a 486/33. > Yeah, but... > The 486 also has an internal 8K cache which offers a substantial >performace improvement over a 386 with an external cache. If you can get away >with using the 386, then sure buy it. If you want more power, get the 486. But is the increase in performance worth the increase in price? Given the 486's current market price I would think not (IMHO of course). Most people also subscribe to the notion that if the number is higher it's necessarily much more powerful, where in fact: (486 - 386) < (286 - 86) << (386 - 286). +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
brandis@inf.ethz.ch (Marc Brandis) (04/05/91)
In article <1991Apr4.204923.29300@agate.berkeley.edu> c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) writes: >Most people also subscribe to the notion that if the number is higher it's >necessarily much more powerful, where in fact: > (486 - 386) < (286 - 86) << (386 - 286). Well, I guess you subscribe to a similar notion which is also wrong, like most performance comparisons that oversimplify. In fact, (386-286) is the smallest of the differences, not by far the largest as your relation indicates. Give me any instruction on the 386 except multiplies that are faster than on the 286. I know you will not find one. Of course, I am comparing apples to apples and oranges to oranges, namely CPUs running in the same mode at the same clock frequency. While it is true that the 486 is not that much faster than the 386 on non-fp code running 16-bit software, you should see a larger difference running 32-bit code. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
osmoviita@cc.helsinki.fi (04/06/91)
In article <1991Apr4.142742.20601@lonex.radc.af.mil>, andrewsh@lonex.radc.af.mil (Harold G. Andrews II) writes: > > Yeah, but... > > The 486 also has an internal 8K cache which offers a substantial > performace improvement over a 386 with an external cache. If you can get away > with using the 386, then sure buy it. If you want more power, get the 486. > > > -Andy > > ******************************************************************************* > * Harold G. "Andy" Andrews II, 1Lt, USAF * "Many the man whose punctuality * > * andrewsh@lonex.radc.af.mil * serves only to warm his chair." * But I compared 33 Mhz 486 with 8k cache and 25 MHz 386 with 64k cache. The 25 MHz 386 was faster in some tests until I added additional cache to 486. Then the performance of 486 was 4-5 times the performance without cache. That was only in tests using lots of memory (e.g. 12 MB). -Kari
c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) (04/06/91)
In article <27865@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes: >In article <1991Apr4.204923.29300@agate.berkeley.edu> c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) writes: >>Most people also subscribe to the notion that if the number is higher it's >>necessarily much more powerful, where in fact: >> (486 - 386) < (286 - 86) << (386 - 286). >Well, I guess you subscribe to a similar notion which is also wrong, like most >performance comparisons that oversimplify. In fact, (386-286) is the smallest ^^^^^^^^^^^^^^^^^^^^^^^^^ >of the differences, not by far the largest as your relation indicates. Give ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >me any instruction on the 386 except multiplies that are faster than on the >286. I know you will not find one. My comparison was of features, not speed. The difference between the 386 and the 286 is vast. The 386 is 32-bit while the 286 is 16-bit. The 386 can split itself into four concurrent 8086's, each with their own 1M memory space, thereby allowing true multitasking. And the 386 can access a 4G address space, while the 286 is limited to a mere 16M. The 286's main advantage over the 86 is its ability to map 16M of extended memory. Therefore, I reason that (386 - 286) >> (286 - 86). The 486's main advantage over the 386 is the built-in math coprocessor. However, this is somewhat of a null feature because it just saves you some money and some space on the motherboard. That is why I reason that it is the smallest difference. >Of course, I am comparing apples to apples and oranges to oranges, >namely CPUs running in the same mode at the same clock frequency. What you are comparing is apples to oranges. The 386 is a 32-bit processor while the 286 is a 16-bit processor. It is in a different league altogether. >While it is true that the 486 is not that much faster than the 386 on non-fp >code running 16-bit software, you should see a larger difference running >32-bit code. Perhaps, but since the majority of MSDOS software contains 16-bit code, the 486 does not offer much realistic speed improvement. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
torvalds@cc.helsinki.fi (04/07/91)
In article <27865@neptune.inf.ethz.ch>, brandis@inf.ethz.ch (Marc Brandis) writes: > In article <1991Apr4.204923.29300@agate.berkeley.edu> c60b-1eq@web-1c.berkeley.edu (Noam Mendelson) writes: >>Most people also subscribe to the notion that if the number is higher it's >>necessarily much more powerful, where in fact: >> (486 - 386) < (286 - 86) << (386 - 286). > > Well, I guess you subscribe to a similar notion which is also wrong, like most > performance comparisons that oversimplify. In fact, (386-286) is the smallest > of the differences, not by far the largest as your relation indicates. Give > me any instruction on the 386 except multiplies that are faster than on the > 286. I know you will not find one. Of course, I am comparing apples to apples > and oranges to oranges, namely CPUs running in the same mode at the same clock > frequency. I don't think speed was the primary difference meant here between the 286 vs the 386. The main point is that "featurewise" the gap between the 286 and 386 is much larger than between the 386 and 486. Quite frankly the x86 family before the 386 is brain-dead (I just LOVE to be flamed :-), while the differences between the 386/486 are mostly cosmetic. Yes - the 486 has an in-built FPU, and some cache. Both these things are easy to add later to a 386, and while not as fast, it becomes functionally about 99% eqvivalent. But why do you think there are a LOT of programs that simply won't work on a 286 or less? (windows "kind of" works on these, but most u*ix etc want a 386 at least). Fos a machine running just dos, the only NOTABLE difference between ANY x86 is speed, so there you could use a 8088 at 500MHz if they made them. For anything else (read unix, windows, etc) you want a 386 or a 486 (yes I'm oversimplifying). The 286 just won't cut it. > > While it is true that the 486 is not that much faster than the 386 on non-fp > code running 16-bit software, you should see a larger difference running > 32-bit code. > Yes - the 486 is faster, but that's about it. It has a few new commands, most of which are cache-controlling commands, and as such "never" used. Linus "God, not the flamethrower .. ahhhh" Torvalds
c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) (04/07/91)
In article <1991Apr6.191106.5863@cc.helsinki.fi> torvalds@cc.helsinki.fi writes: >... But why do you think there are a LOT >of programs that simply won't work on a 286 or less? (windows "kind of" >works on these, but most u*ix etc want a 386 at least). Just a technical point--UN*X Sys V can run on an 8086. And an 80286-based system can make a workable multi-user UN*X system. > Fos a machine running just dos, the only NOTABLE difference between >ANY x86 is speed, so there you could use a 8088 at 500MHz if they made >them. A few years ago I read about a 50 MHz 80286 system created by a Japanese designer. The only major modification was the addition of a heat sink to the CPU. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
mikes@iuvax.cs.indiana.edu (Michael Squires) (04/08/91)
In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: > >Perhaps, but since the majority of MSDOS software contains 16-bit code, >the 486 does not offer much realistic speed improvement. My 486/25 under DOS clocks at about 15,000 Dhrystones/sec. This is about 2x my 386/20 with 64K cache; I would expect a 386/33 with cache to clock at about the same speed. The same system running SCO UNIX V 3.2.1 clocks at 21,000 Dhrystones/sec. (SCO UNIX runs in 386 mode, and compiler generates 32-bit 386 code). DOS applications running under DOS-Merge run at about the speed of 386/20 (DOS applications running under DOS Merge on the 386/20 run at the speed of a 10MHZ 286). -- Mike Squires (mikes@iuvax.cs.indiana.edu) 812 855 3974 (w) 812 333 6564 (h) mikes@iuvax.cs.indiana.edu 546 N Park Ridge Rd., Bloomington, IN 47408 Under construction: mikes@sir-alan.cica.indiana.edu
mikes@iuvax.cs.indiana.edu (Michael Squires) (04/08/91)
In article <1991Apr6.021141.5859@cc.helsinki.fi> osmoviita@cc.helsinki.fi writes: >But I compared 33 Mhz 486 with 8k cache and 25 MHz 386 with 64k cache. The >25 MHz 386 was faster in some tests until I added additional cache to 486. >Then the performance of 486 was 4-5 times the performance without cache. >That was only in tests using lots of memory (e.g. 12 MB). My 486/25 has only the internal 8K cache. With the AMI BIOS/OPTI chipset it turns out that the range of memory which could be cached was set by the XCMOS settings even when the 8K cache was turned on using jumpers. I could not understand why a 486/25 was slower than a 386/20 running UNIX; it turned out that the 8K cache was only working in the first 1MB. -- Mike Squires (mikes@iuvax.cs.indiana.edu) 812 855 3974 (w) 812 333 6564 (h) mikes@iuvax.cs.indiana.edu 546 N Park Ridge Rd., Bloomington, IN 47408 Under construction: mikes@sir-alan.cica.indiana.edu
c60b-1eq@web-1e.berkeley.edu (Noam Mendelson) (04/08/91)
In article <1991Apr7.170017.23962@news.cs.indiana.edu> mikes@iuvax.cs.indiana.edu (Michael Squires) writes: >In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: >> >>Perhaps, but since the majority of MSDOS software contains 16-bit code, >>the 486 does not offer much realistic speed improvement. > >My 486/25 under DOS clocks at about 15,000 Dhrystones/sec. This is about 2x >my 386/20 with 64K cache; I would expect a 386/33 with cache to clock at about >the same speed. At least. Given an identical clock speed, the 80486 CPU should be about 50% faster than the 80386 CPU. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
brandis@inf.ethz.ch (Marc Brandis) (04/08/91)
In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: >>>Most people also subscribe to the notion that if the number is higher it's >>>necessarily much more powerful, where in fact: >>> (486 - 386) < (286 - 86) << (386 - 286). >>Well, I guess you subscribe to a similar notion which is also wrong, like most >>performance comparisons that oversimplify. In fact, (386-286) is the smallest > ^^^^^^^^^^^^^^^^^^^^^^^^^ >>of the differences, not by far the largest as your relation indicates. Give > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>me any instruction on the 386 except multiplies that are faster than on the >>286. I know you will not find one. > >My comparison was of features, not speed. The difference between the >386 and the 286 is vast. The 386 is 32-bit while the 286 is 16-bit. Well, if you are comparing features you are right. But this discussion was not about features. Probably we should define what we mean by 'powerful'. Anyway, as long as you are running DOS software you will not get too many benefits from the 32-bit architecture, if none. E.g. the advantages the 386 offers in running Windows does not have anything to do with the 32-bit architecture but with the added paging-unit and the added VM-86 mode. >The 386 can split itself into four concurrent 8086's, each with their >own 1M memory space, thereby allowing true multitasking. Wrong. The 386 can support as many "concurrent 8086's" as you like, even more than you have memory (using virtual memory). I do not know where you have this number four from, but it is wrong. >And the 386 >can access a 4G address space, while the 286 is limited to a mere 16M. >The 286's main advantage over the 86 is its ability to map 16M of >extended memory. Therefore, I reason that (386 - 286) >> (286 - 86). The 286 offers protection, 1 GB virtual memory etc. If you do not count these features because they are not used by DOS (software developers programming for protected mode really appreciate these features), you should not count the 386 features that DOS does not use either. So, where is the difference then. Anyway, as long as you stay in the DOS world, 16M of memory is plenty enough. >The 486's main advantage over the 386 is the built-in math coprocessor. >However, this is somewhat of a null feature because it just saves >you some money and some space on the motherboard. That is why I reason >that it is the smallest difference. I do not agree. The main advantage in my opinion is the reduced CPI (cycles per instruction) count. The fact that you do not see this advantage well enough when running DOS programs is not the 486's fault. > >>Of course, I am comparing apples to apples and oranges to oranges, >>namely CPUs running in the same mode at the same clock frequency. > >What you are comparing is apples to oranges. The 386 is a 32-bit processor >while the 286 is a 16-bit processor. It is in a different league altogether. Since end-users are not in the role to recompile programs, they have to compare the same program running on different processors. They will not notice any of the benefits of the 32-bit architecture. > >>While it is true that the 486 is not that much faster than the 386 on non-fp >>code running 16-bit software, you should see a larger difference running >>32-bit code. > >Perhaps, but since the majority of MSDOS software contains 16-bit code, >the 486 does not offer much realistic speed improvement. If you use this argument (compatibility to DOS programs), you should use it uniformly over all members of the family, including the 386. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
brandis@inf.ethz.ch (Marc Brandis) (04/08/91)
In article <1991Apr6.191106.5863@cc.helsinki.fi> torvalds@cc.helsinki.fi writes: >In article <27865@neptune.inf.ethz.ch>, brandis@inf.ethz.ch (Marc Brandis) writes: > Fos a machine running just dos, the only NOTABLE difference between >ANY x86 is speed, so there you could use a 8088 at 500MHz if they made >them. For anything else (read unix, windows, etc) you want a 386 or a >486 (yes I'm oversimplifying). The 286 just won't cut it. > That was exactly my point. As far as I remember the original question was about a system to run DOS. With Windows you get the benefits of VM86 and of the paging unit, but not of the 32-bit architecture (and I do not think that the advantage of Windows in enhanced (speak 386) mode vs. Windows in standard (speak 286) mode is as large as the advantage of Windows in standard mode vs. Windows in real (speak 8086) mode. For UNIX, I could not agree with you more. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
martin@saturn.uucp (Martin J. Schedlbauer) (04/08/91)
In article <1991Apr7.232941.21382@agate.berkeley.edu> c60b-1eq@web-1e.berkeley.edu (Noam Mendelson) writes: >In article <1991Apr7.170017.23962@news.cs.indiana.edu> mikes@iuvax.cs.indiana.edu (Michael Squires) writes: >>In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: >>> >>>Perhaps, but since the majority of MSDOS software contains 16-bit code, >>>the 486 does not offer much realistic speed improvement. I recently upgraded from a 386-25 (64k cache) to a 486-25 (8k + 128k cache). It is faster than before but not by much under DOS. I found that Windows 3.0 performance is indeed better. Many 486 system allow one to disable caching of memory in the upper address ranges. This is important for memory-mapped I/O cards such as VGA, etc. Under Unix I found the system to be drastically better and the floating point hardware is considerably faster under both DOS and Unix than the 387-25. If you are running mainly 16bit DOS (i.e. no 386 extender DOS) and you don't need floating point hardware, a 386-25 is the most economical. If you do need FP performance, go for a 486. It's cheaper than a 386+387. ...Martin -- ============================================================================== Martin J. Schedlbauer | martin@saturn.UUCP | ...!ulowell!saturn!martin 8 Gilman Road | mschedlb@ulowell.edu | ...!uunet!wang!saturn!martin Billerica, MA 01862 USA | CIS: 76675, 3364 | Voice/Fax: (508) 670-2169
edm@hpfcmdd.hp.com (Ed Moore) (04/09/91)
The 12/25/90 issue of PC Magazine, page 169, claims that a 386/33 gives more bang for the buck if a math coprocessor isn't needed.
marz@cbnewsb.cb.att.com (martin.zam) (04/09/91)
In Article: 7760 of comp.sys.ibm.pc.hardware, c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >Just a technical point--UN*X Sys V can run on an 8086. And an 80286-based >system can make a workable multi-user UN*X system. ^ | Just what port of REAL UNIX Sys V where you thinking of when you wrote this?!?! Martin Zam (201)564-2554
c60b-1eq@e260-3e.berkeley.edu (Noam Mendelson) (04/10/91)
In article <1991Apr9.150055.13705@cbfsb.att.com> marz@cbnewsb.cb.att.com (martin.zam) writes: >In Article: 7760 of comp.sys.ibm.pc.hardware, >c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >>Just a technical point--UN*X Sys V can run on an 8086. And an 80286-based >>system can make a workable multi-user UN*X system. >Just what port of REAL UNIX Sys V where you thinking of when you wrote this?!?! I wasn't ambitious enough to undertake such a project, but I know someone who did. UN*X can theoretically be run within the bounds of 640K, swapping processes to the hard disk (very, very often). +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
c60b-1eq@e260-3e.berkeley.edu (Noam Mendelson) (04/10/91)
In article <1991Apr8.154643.784@saturn.uucp> martin@saturn.UUCP (Martin J. Schedlbauer) writes: >In article <1991Apr7.232941.21382@agate.berkeley.edu> c60b-1eq@web-1e.berkeley.edu (Noam Mendelson) writes: >>In article <1991Apr7.170017.23962@news.cs.indiana.edu> mikes@iuvax.cs.indiana.edu (Michael Squires) writes: >>>In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: >>>>Perhaps, but since the majority of MSDOS software contains 16-bit code, >>>>the 486 does not offer much realistic speed improvement. >If you are running mainly 16bit DOS (i.e. no 386 extender DOS) and you don't >need floating point hardware, a 386-25 is the most economical. >If you do need FP performance, go for a 486. It's cheaper than a 386+387. That's exactly the message I tried to get across. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
lbr@holos0.uucp (Len Reed) (04/11/91)
In article <1991Apr7.033635.18412@agate.berkeley.edu> c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >Just a technical point--UN*X Sys V can run on an 8086. Of course a stray pointer can bring down the whole house of cards. >And an 80286-based system can make a workable multi-user UN*X system. But the point being made was that 16-bit addressing really cripples you. Once upon a time Unix ran on PDP-11's, but system V really doesn't work too well on anything less than a 32-bit processor. Of course, I can't imagine why anyone would buy anything less than a 80386-SX even for a home computer running DOS; they've become so cheap that arguing over whether a 286 is adaquate is as dumb as arguing if an 8080 would do the job. Who cares? -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/11/91)
In article <27865@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes: | Well, I guess you subscribe to a similar notion which is also wrong, like most | performance comparisons that oversimplify. In fact, (386-286) is the smallest | of the differences, not by far the largest as your relation indicates. Give | me any instruction on the 386 except multiplies that are faster than on the | 286. I know you will not find one. Of course, I am comparing apples to apples | and oranges to oranges, namely CPUs running in the same mode at the same clock | frequency. Fortunately we don't have to do that in the real world. We are interested in how long it takes to get the computing done, and therefore aren't limited to models which run on the 8086, nor at the same clock frequency. In truth using the same mode and clock, only the 386->486 shows a major improvement. For real world problems, using arrays larger than 32k, integers larger than 32k, and float values, the 386 in it's best (protected) mode is about twice as fast as a 286, and the 486 is about twice as fast as the 386, *at the same clock speed*. This is not to knock direct comparisons, because if you're running a 64k application which only accesses bytes, and you are allergic to frequencies faster than 4.77 MHz, or if you are comparing a 20MHz 286 vs 386, then the heads up comparison yields some useful info. For typical problems with source code, protected mode 386 or 486 run much faster, even at the same clock, and the 486 uses fewer clock cycles for most instructions, and with its burst mode supported in hardware it runs faster yet due to fewer effective wait states. Comparing the fastest mode and model for each CPU isn't "fair" for a frozen application, but the real world isn't fair, and applications get updated to use the extra power. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/11/91)
In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: | My comparison was of features, not speed. The difference between the | 386 and the 286 is vast. The 386 is 32-bit while the 286 is 16-bit. | The 386 can split itself into four concurrent 8086's, each with their | own 1M memory space, thereby allowing true multitasking. May I commend to you rereading the section on the virtual 8086 mode. You are reading into the manual something Intel didn't write into their chip. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/11/91)
In article <1991Apr6.021141.5859@cc.helsinki.fi> osmoviita@cc.helsinki.fi writes: | But I compared 33 Mhz 486 with 8k cache and 25 MHz 386 with 64k cache. The | 25 MHz 386 was faster in some tests until I added additional cache to 486. | Then the performance of 486 was 4-5 times the performance without cache. | That was only in tests using lots of memory (e.g. 12 MB). That sounds like a system without burst mode refresh. A system with burst mode will typically show a much smaller benefit from cache, no matter what the access pattern. Note: this is not true for all possible patterns, so I am drawing a conclusion based on limited facts. However, I would be happy if you care able to confirm this. I got some benchmarks on this from the A.I.R. people who advertise in the back of _Info World_. Since they sell with and without cache, I assume they don't have a reason to try and make the burst mode machines look good. I got a chance to try a few tests on a machine at work, and I agree that a machine with burst mode and no external cache is *usually* faster than a machine with external cache and no burst mode. My opinion and experience only. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/11/91)
In article <1991Apr7.033635.18412@agate.berkeley.edu> c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: | Just a technical point--UN*X Sys V can run on an 8086. And an 80286-based | system can make a workable multi-user UN*X system. Your second statement is very true. I question the first. I've run SysIII on an 8086, but where did you find SysV? There is a Xenix version for 8086, but as far as I can tell it is based on an enhanced V7 kernel, and doesn't support shared memory and {I forget, one other major feature} until you get to Xenix/286. There was also a Venix for 8086, but I am 90% siure that was not a SysV kernel, either. So what system are you thinking of? -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/11/91)
In article <1991Apr8.154643.784@saturn.uucp> martin@saturn.UUCP (Martin J. Schedlbauer) writes: | Many 486 system allow one to disable caching of memory in the upper address | ranges. This is important for memory-mapped I/O cards such as VGA, etc. ??? who's VGA are you running? I have never seen one mapped above the first MB. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) (04/11/91)
In article <1991Apr11.001619.6952@holos0.uucp> lbr@holos0.uucp (Len Reed) writes: >In article <1991Apr7.033635.18412@agate.berkeley.edu> c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >>Just a technical point--UN*X Sys V can run on an 8086. >Of course a stray pointer can bring down the whole house of cards. Yep. >>And an 80286-based system can make a workable multi-user UN*X system. >But the point being made was that 16-bit addressing really cripples you. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ On a 286? 24 bits. >Once upon a time Unix ran on PDP-11's, but system V really doesn't work >too well on anything less than a 32-bit processor. Agreed. >Of course, I can't imagine why anyone would buy anything less than a >80386-SX even for a home computer running DOS; they've become so cheap that >arguing over whether a 286 is adaquate [sic] is as dumb as arguing if an 8080 >would do the job. Who cares? Maybe you don't, but for others it's a prime consideration. For example, if you use your PC mainly as a terminal, the speed of the CPU won't help you much. It all depends on what applications you use it for. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
berggren@eecs.cs.pdx.edu (Eric Berggren) (04/11/91)
brandis@inf.ethz.ch (Marc Brandis) writes: >In article <1991Apr6.191106.5863@cc.helsinki.fi> torvalds@cc.helsinki.fi writes: >>In article <27865@neptune.inf.ethz.ch>, brandis@inf.ethz.ch (Marc Brandis) writes: >> Fos a machine running just dos, the only NOTABLE difference between >>ANY x86 is speed, so there you could use a 8088 at 500MHz if they made >>them. For anything else (read unix, windows, etc) you want a 386 or a >>486 (yes I'm oversimplifying). The 286 just won't cut it. >> >That was exactly my point. As far as I remember the original question was about >a system to run DOS. With Windows you get the benefits of VM86 and of the >paging unit, but not of the 32-bit architecture (and I do not think that the >advantage of Windows in enhanced (speak 386) mode vs. Windows in standard >(speak 286) mode is as large as the advantage of Windows in standard mode vs. >Windows in real (speak 8086) mode. For UNIX, I could not agree with you more. Sigh... Must be nice to spend several thousand dollars on a 486 system to run MS-DOS. <grumble...> Anyway, I'm looking into either an upper-end 386 or a low end 486. I'm being told after adding a 387, I would be within around $600 to a 486 board. Other than speed, I can't _really_ see the big difference, since the 386 board has 128k cache... -e.b. ============================================================================== Eric Berggren | "Life is a Turing Test; Computer Science/Eng. | We're all automatons!" berggren@eecs.cs.pdx.edu | - (click, whir, buzz, chirp)
berggren@eecs.cs.pdx.edu (Eric Berggren) (04/11/91)
c60b-1eq@e260-3e.berkeley.edu (Noam Mendelson) writes: >In article <1991Apr9.150055.13705@cbfsb.att.com> marz@cbnewsb.cb.att.com (martin.zam) writes: >>In Article: 7760 of comp.sys.ibm.pc.hardware, >>c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >>>Just a technical point--UN*X Sys V can run on an 8086. And an 80286-based >>>system can make a workable multi-user UN*X system. >>Just what port of REAL UNIX Sys V where you thinking of when you wrote this?!?! >I wasn't ambitious enough to undertake such a project, but I know someone who >did. UN*X can theoretically be run within the bounds of 640K, swapping processes >to the hard disk (very, very often). Hmmm, I seem to recall strict memory management under UNIX (user and kernel mode, etc) I'm upgrading strictly for the purpose of running UNIX; DOS would be history... -e.b. ============================================================================== Eric Berggren | "Life is a Turing Test; Computer Science/Eng. | We're all automatons!" berggren@eecs.cs.pdx.edu | - (click, whir, buzz, chirp)
berggren@eecs.cs.pdx.edu (Eric Berggren) (04/11/91)
lbr@holos0.uucp (Len Reed) writes: >In article <1991Apr7.033635.18412@agate.berkeley.edu> c60b-1eq@e260-1f.berkeley.edu (Noam Mendelson) writes: >>Just a technical point--UN*X Sys V can run on an 8086. >Of course a stray pointer can bring down the whole house of cards. >>And an 80286-based system can make a workable multi-user UN*X system. >But the point being made was that 16-bit addressing really cripples you. That's 64k, is that what you mean? 8088/86 use 20-bit addressing. (just nit picking..) >Once upon a time Unix ran on PDP-11's, but system V really doesn't work >too well on anything less than a 32-bit processor. >Of course, I can't imagine why anyone would buy anything less than a >80386-SX even for a home computer running DOS; they've become so cheap that >arguing over whether a 286 is adaquate is as dumb as arguing if an 8080 >would do the job. Who cares? ^ | Ahhh, the origins of our wonderful and ubiquitous MSDOS! | -e.b. ============================================================================== Eric Berggren | "Life is a Turing Test; Computer Science/Eng. | We're all automatons!" berggren@eecs.cs.pdx.edu | - (click, whir, buzz, chirp)
mlord@bwdls58.bnr.ca (Mark Lord) (04/11/91)
In article <> brandis@inf.ethz.ch (Marc Brandis) writes:
<That was exactly my point. As far as I remember the original question was about
<a system to run DOS. With Windows you get the benefits of VM86 and of the
<paging unit, but not of the 32-bit architecture (and I do not think that the
<advantage of Windows in enhanced (speak 386) mode vs. Windows in standard
<(speak 286) mode is as large as the advantage of Windows in standard mode vs.
<Windows in real (speak 8086) mode.
The 32-bit architecture of a 386 provides immediate performance benefits
to MS-DOS users in *at least* the following significant ways:
1) PKZIP takes full advantage of the 32-bit regs/instructions
so as to gain maximum performance on a 386. Not that any of
us actually use .ZIP files regularly. :)
2) The motherboard BIOS typically takes great advantage of the
32-bit regs/instructions to aid performance.
3) Extended memory managers (QEMM,386^MAX etc), which are among
the most popular commercial software, also take full advantage of
the 32-bit archictecture to maximize performance, especially when
performing copies to/from extended memory via the XMS interface.
4) Disk caching programs, such as HYPERDISK, take full advantage
of the 32-bit instructions and registers for maximum performance.
5) The Windows 3.0 386-kernel uses 32-bit registers and instructions
internally.
6) *All* code, including the oldest 8/16 bit programs, gain a slight
increment from automatic use of the 32-bit wide instruction prefetch
queue of the 386, which can hold up to twice the data of the 16-bit
queue of the 8086/80286.
That's all I could think of in two minutes. Of course, others have already
reminded us all of the *other* benefits of the 386 virtual architecture,
which by itself is enough reason for never again purchasing anything less
than a 386 for a general purpose personal computer.
--
MLORD@BNR.CA Ottawa, Ontario *** Personal views only ***
begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE
MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS
<^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5
``
endjohn@jwt.UUCP (John Temples) (04/14/91)
In article <1991Apr11.073556.9556@agate.berkeley.edu> c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >>But the point being made was that 16-bit addressing really cripples you. > >On a 286? 24 bits. No, 16 bits is all you can address in one chunk. That's what's really crippling. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
john@jwt.UUCP (John Temples) (04/15/91)
In article <3669@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <1991Apr6.045408.15395@agate.berkeley.edu> c60b-1eq@e260-1d.berkeley.edu (Noam Mendelson) writes: >| The 386 can split itself into four concurrent 8086's >May I commend to you rereading the section on the virtual 8086 mode. This is the second time I've seen someone claim there was a limit of four virtual machines in V86 mode. I wonder where this particular urban legend got its start? Does one of the DOS multitaskers have a limit of four concurrent tasks? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
berggren@eecs.cs.pdx.edu (Eric Berggren) (04/16/91)
john@jwt.UUCP (John Temples) writes: >In article <1991Apr11.073556.9556@agate.berkeley.edu> c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >>>But the point being made was that 16-bit addressing really cripples you. >> >>On a 286? 24 bits. >No, 16 bits is all you can address in one chunk. That's what's really >crippling. Well, yeah. That's true. Now to find whose neck to wring :-> -e.b. ============================================================================== Eric Berggren | "Life is a Turing Test; Computer Science/Eng. | We're all automatons!" berggren@eecs.cs.pdx.edu | - (click, whir, buzz, chirp)
lbr@holos0.uucp (Len Reed) (04/16/91)
In article <2328@pdxgate.UUCP> berggren@eecs.cs.pdx.edu (Eric Berggren) writes: >lbr@holos0.uucp (Len Reed) writes: > >>But the point being made was that 16-bit addressing really cripples you. > > That's 64k, is that what you mean? 8088/86 use 20-bit addressing. (just >nit picking..) I'm not talking about how much memory the chip can address but rather how much memory a program can *efficiently* address. Index registers and memory offsets are 16-bits. The other 4 bits can be used only at great pain. To deal with data spaces greater than 64 K-bytes you have to fool with the segment registers. Consider the following: extern int *p, q, *r; q = *p; r = p; In 32-bit 386 mode, this is something like mov ecx, [p] ; 1 memory access mov [r], ecx ; 1 memory access mov eax, [ecx] ; 1 memory access mov [q], eax ; 1 memory access For small-model C on the 8088/8086 we get pretty much the same. (Though our integers are only 16 bits, and we are restricted to BX/DI/SI for pointers.) But if we have to go to large model, things get ugly. Microsoft 6.0 with optimization on full came up with the following: mov es,[segment_of_p] ; 1 memory access (*) les bx,es:[p] ; 2 mov ax,es:[bx] ; 1 mov cx,es mov es,[segment_of_q] ; 1 (*) mov es:[q],ax ; 1 mov es,[segment_of_r] ; 1 (*) mov es:[r],bx ; 1 mov es:[r+2],cx ; 1 (total is 9) (*) It could be a tiny bit faster if the compiler used immediate moves to load the ES register. E.g., the first one would be. mov ax, segment p mov es, ax The compiler has really jumped through hoops here to deal with addresses beyond 16 bits. And we're only getting 16-bit integers, too. It doesn't much more code before the optimization seen above starts to break down because we need 2 registers to hold a pointer or a long and because only the [bx], [si], [di], [bx+si], [bx+di] are available for addresses. The 386 allows stuff like [eax + 4*ecx], which is nice for accessing arrays. My example went from 4 instructions with 4 memory accesses to 9 and 9. The point at which this catastrophe of inefficiency occurs is when we wish to access more that 64 K of data. -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr
russ@pmafire.inel.gov (Russ Brown) (04/16/91)
In article <2326@pdxgate.UUCP> berggren@eecs.cs.pdx.edu (Eric Berggren) writes: >brandis@inf.ethz.ch (Marc Brandis) writes: > >>In article <1991Apr6.191106.5863@cc.helsinki.fi> torvalds@cc.helsinki.fi writes: >>>In article <27865@neptune.inf.ethz.ch>, brandis@inf.ethz.ch (Marc Brandis) writes: >>> Fos a machine running just dos, the only NOTABLE difference between >>>ANY x86 is speed, so there you could use a 8088 at 500MHz if they made >>>them. For anything else (read unix, windows, etc) you want a 386 or a >>>486 (yes I'm oversimplifying). The 286 just won't cut it. > > Sigh... Must be nice to spend several thousand dollars on a 486 system to >run MS-DOS. <grumble...> > >============================================================================== > Eric Berggren | "Life is a Turing Test; If you have stuff that can be done best on DOS, why not. I have an 80486-33 Dell 433TE; runs UNIX V 5.4 (upgrade due out any day now) **and** MS-DOS under DOSMerge. Some of the DOS database and graphics conversions typically ran 40 minutes and one job took 6.5 hours on an 80386-20. The 486 saves lots of time. My DOS database is so highly customized that it could not (at least now) be done on any other operating system. My graphics involve the serial product of two databases and a DOS graphics program, which convert 30 years worth of U.S. cancer mortality into 3-d color-coded topo maps. I could use an 80586-100 if it were available....(with refrigerator; :<)).
daly@ecs.umass.edu (Bryon Daly, ECE dept, UMass, Amherst) (04/16/91)
In article <1991Apr14.163703.4175@jwt.UUCP>, john@jwt.UUCP (John Temples) writes: > In article <1991Apr11.073556.9556@agate.berkeley.edu> c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >>>But the point being made was that 16-bit addressing really cripples you. >> >>On a 286? 24 bits. > > No, 16 bits is all you can address in one chunk. That's what's really > crippling. > -- > John W. Temples -- john@jwt.UUCP (uunet!jwt!john) No, 24 bits (in protected mode, and 20 in real mode) in what you can address on a 286. Really. The "16-bitness" of a 286 refers to its data width. The 286 can address the full 16 MB of it's address space without having to multiplex it's address bus 16 bits at a time. (Note: 16 bit address space is only 64K). It also does not split the 24 bit address into 16/8. -Bryon daly@ecs.umass.edu
john@jwt.UUCP (John Temples) (04/21/91)
In article <13238.280ad858@ecs.umass.edu> daly@ecs.umass.edu (Bryon Daly, ECE dept, UMass, Amherst) writes: >> No, 16 bits is all you can address in one chunk. ^^^^^^^^^^^^ >No, 24 bits (in protected mode, and 20 in real mode) Ok, show me some 286 code that steps through all 16 megabytes of its address space, incrementing a single offset register as it goes. No fair updating other "segment" registers, since you're then stepping through different "chunks"! If I can address 20 bits in real mode in one chunk, why can't my DOS C compiler grok "char foo[300000];" ? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
herder@myab.se (Jan Herder) (04/23/91)
In article <1991Apr14.230407.5019@jwt.UUCP> john@jwt.UUCP (John Temples) writes: > >This is the second time I've seen someone claim there was a limit of four >virtual machines in V86 mode. I wonder where this particular urban legend >got its start? Does one of the DOS multitaskers have a limit of four >concurrent tasks? Concurrent DOS, Digital Research combination of CCP/M and DOS had the possibility of running four different DOS sessions each connected to a virtual terminal you could switch between. This was done on a 808[86]. This is the only one I knew of. -- Jan Herder, FORDONSDATA Sweden | Phone: +46 31 18 75 12 Internet: herder@myab.se | Fax: +46 31 18 28 42 UUCP: uunet!sunic!chalmers!myab!herder | Address: Dr. Forseliusg 21 ARPA: herder%myab.se@uunet.uu.net | 413 26 Gothenburg