lj359831@longs.LANCE.ColoState.EDU (Lee Jarvie) (09/19/90)
Just have to get in my 2 cents. A 386sx is a great machine. Granted, it is a little slower, but don't worry about it. It's not that slow. I have one myself with HD floppies, VGA, trackball and 110 Meg hard drive. I love it. It is a desktop model and is smaller than the XT's I see around. They're a great little machine, don't worry about any bad reviews. Lee lj359831@longs.lance.colostate.edu
alas@eniac.seas.upenn.edu (David J. Alas) (12/06/90)
I was looking to pick up a 386 compatible system. Our company's interest lies in productivity but at a reasonable cost. However, due to past problems (as much as I'd like to get a clone), the people here only want IBM. That being the case, I was wondering what the significant differences are between the IBM PS/2 Model 55SX (386SX) and the Model 70 (386) other than the slightly slower throughput speed of the SX. -- ______________________________________________________________________________ -- David Alas alas@eniac.seas.upenn.edu "If you pick up a starving dog and make it prosperous, it will not bite you. This is the principal difference between a dog and a man." -- Mark Twain
draper@buster.cps.msu.edu (Patrick J Draper) (12/06/90)
In article <34117@netnews.upenn.edu> alas@eniac.seas.upenn.edu (David J. Alas) writes: >I was looking to pick up a 386 compatible system. Our company's interest >lies in productivity but at a reasonable cost. However, due to past problems >(as much as I'd like to get a clone), the people here only want IBM. >That being the case, I was wondering what the significant differences >are between the IBM PS/2 Model 55SX (386SX) and the Model 70 (386) >other than the slightly slower throughput speed of the SX. > > > >-- >______________________________________________________________________________ >-- David Alas alas@eniac.seas.upenn.edu >"If you pick up a starving dog and make it prosperous, it will not bite you. >This is the principal difference between a dog and a man." -- Mark Twain In my experience, running MS-DOS an SX is equally fast as a full 386. I think that is because MS-DOS is a 16-bit system, and runs in 16 bit real mode of 386's. Therefore there is no speed advantage from the 32 bit bus. I may be wrong, and I'm sure someone will correct me if I am. The SX can address 16 Mb of RAM vs. the full 386's 4gigabytes. ------------------------------------------------------------------------ Patrick Draper In times like these it is helpful to buster.cps.msu.edu remember that there have always been times like these. ------------------------------------------------------------------------
silver@xrtll.uucp (Hi Ho Silver) (12/10/90)
In article <1990Dec5.211220.13194@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes:
$In my experience, running MS-DOS an SX is equally fast as a full 386. I
$think that is because MS-DOS is a 16-bit system, and runs in 16 bit real
$mode of 386's. Therefore there is no speed advantage from the 32 bit
$bus. I may be wrong, and I'm sure someone will correct me if I am.
You're just a little off. The 386DX does its instruction fetches
32 bits at a time, whereas the 386SX (obviously) can't fetch more than
16 bits at a time. This gives the DX somewhat higher performance for
the same clock rate on 16-bit software.
Keep in mind, also, that there is some software that is 386-specific,
and the speed difference will be greater for that software than for
16-bit software; also, there are some programs that detect if you have a
386 installed and will transparently use it if so (PKZIP/PKUNZIP, for
example).
--
__ __ _ | ...!nexus.yorku.edu!xrtll!silver | always
(__ | | | | |_ |_) >----------------------------------< searching
__) | |_ \/ |__ | \ | if you don't like my posts, type | for
_____________________/ find / -print|xargs cat|compress | SNTFkaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (12/11/90)
In article <1990Dec10.024523.21545@xrtll.uucp> silver@xrtll.UUCP (Hi Ho Silver) writes: >In article <1990Dec5.211220.13194@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes: >$In my experience, running MS-DOS an SX is equally fast as a full 386. I >$think that is because MS-DOS is a 16-bit system, and runs in 16 bit real >$mode of 386's. Therefore there is no speed advantage from the 32 bit >$bus. I may be wrong, and I'm sure someone will correct me if I am. > > You're just a little off. The 386DX does its instruction fetches >32 bits at a time, whereas the 386SX (obviously) can't fetch more than >16 bits at a time. This gives the DX somewhat higher performance for >the same clock rate on 16-bit software. > For what it's worth, I get the following Dhrystone's: (Yeah, I know Dhrystone isn't the do all benchmark; anyone got the source to Bytes' PC benchmarks?) 16mhz 386SX 20mhz 386DX 25mhz 486 Sun 4/330 5000 8000 28000 24000 -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov You can please all of the people some of the time,
jca@pnet01.cts.com (John C. Archambeau) (12/11/90)
silver@xrtll.uucp (Hi Ho Silver) writes: >In article <1990Dec5.211220.13194@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes: >$In my experience, running MS-DOS an SX is equally fast as a full 386. I >$think that is because MS-DOS is a 16-bit system, and runs in 16 bit real >$mode of 386's. Therefore there is no speed advantage from the 32 bit >$bus. I may be wrong, and I'm sure someone will correct me if I am. > > You're just a little off. The 386DX does its instruction fetches >32 bits at a time, whereas the 386SX (obviously) can't fetch more than >16 bits at a time. This gives the DX somewhat higher performance for >the same clock rate on 16-bit software. > > Keep in mind, also, that there is some software that is 386-specific, >and the speed difference will be greater for that software than for >16-bit software; also, there are some programs that detect if you have a >386 installed and will transparently use it if so (PKZIP/PKUNZIP, for >example). This is where you're wrong. There is no way in software to tell the difference between the 386SX and 386DX. It all looks the same to software. Even the prefetch instruction queue is the same length. True, it can only get 16-bits of data at a time, but internally, a 386SX is identical to a 386DX. The only difference if I'm not mistaking is the bus interface unit (limited to 16-bits on an SX, 32-bits on a DX), and the address space (only 24-bit on an SX, 32-bit on a DX) which is limited to 16 Mb physical memory. Otherwise, it's the same thing to software. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
brandis@inf.ethz.ch (Marc Brandis) (12/11/90)
In article <1990Dec10.161538.16651@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) writes: >In article <1990Dec10.024523.21545@xrtll.uucp> silver@xrtll.UUCP (Hi Ho Silver) writes: >>In article <1990Dec5.211220.13194@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes: >>$In my experience, running MS-DOS an SX is equally fast as a full 386. I >>$think that is because MS-DOS is a 16-bit system, and runs in 16 bit real >>$mode of 386's. Therefore there is no speed advantage from the 32 bit >>$bus. I may be wrong, and I'm sure someone will correct me if I am. >> >> You're just a little off. The 386DX does its instruction fetches >>32 bits at a time, whereas the 386SX (obviously) can't fetch more than >>16 bits at a time. This gives the DX somewhat higher performance for >>the same clock rate on 16-bit software. >> > >For what it's worth, I get the following Dhrystone's: >(Yeah, I know Dhrystone isn't the do all benchmark; anyone got the >source to Bytes' PC benchmarks?) > >16mhz 386SX 20mhz 386DX 25mhz 486 Sun 4/330 >5000 8000 28000 24000 > Without any further information these benchmarks do not really tell you anything about the relative performance of an SX to a DX or even a 486 or a Sun 4. What kind of memory system do the used systems have, are they cached or not, how fast is the memory, under which OS were the benchmarks run, what compilers were used ... ? There are a lot of open variables, which affect the performance a lot. I once ran some computational intensive programs on both a 386 SX and a 386 DX, both at 16 MHz, both without a cache and 100 ns RAM. The programs used were identical, compiled with a 16-bit compiler and running under DOS. I noticed a speed difference of about 5% in favor for the DX. This sounds reasonable to me as the 386 is not yet such a fast machine that it becomes heavily bound by the available instruction fetch bandwidth. Note that data references (aligned) do not get any profit out of the 32-bit bus of the DX. From some data about programs on the i80x86 family, I remember that the average instruction length for 16-bit DOS programs is between 2 and 3 bytes, while the average cycles per instruction is a between four and five. Therefore you need only slightly more than one byte of instruction every memory cycle (which is two CPU cycles), or it is almost sufficient to keep the CPU busy to fetch a 16-bit word every second memory cycle, which leaves enough bandwidth for data references. Note that branches do not change the picture a lot, as branches are already very slow on the 386 (9 cycles), so that there should be enough time to fetch the instructions at the target. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
theall@rm105serve.sas.upenn.edu (George A. Theall) (12/11/90)
In article <6242@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >There is no way in software to tell the >difference between the 386SX and 386DX. Recently there was a short piece of code posted to comp.sys.intel by danw@jacobs.cs.orst.edu (Dan Whitaker) which claimed to tell the difference when run on some type of 386 (ie, it's not for XTs or ATs). Though I don't understand the test it employs, it has successfully reported the CPU type when run on several IBM PS/2 Model 80s and 55SXs and an NEC PowerMate SX with which I work. I make no claims that the algorithm used is valid for all machines or configurations. Nonetheless, a slightly reformatted version of Whitaker's code is attached below for those who might be interested yet missed the earlier article. It is coded for TASM and will *not* run under either DESQview or Turbo Debugger! I'd appreciate hearing of your experiences with it, especially if it does *not* work in a particular configuration. --- snip, snip, snip --- ;---------------------------------------------------------------------------; ; Article 1406 of comp.sys.intel: ; From: danw@jacobs.cs.orst.edu (Dan Whitaker) ; Subject: CODE that can tell a 386DX from a 386SX ; Date: 22 Oct 90 22:24:27 GMT ; Organization: Oregon State University - CS - Corvallis Oregon ; ; For all of you that have been looking for a fool proof way to ; tell a 386DX from a 386SX, there it is. (Source code included) ; ; Dan Whitaker wk (503) 757-0934 FAX (503) 757-7350 ;---------------------------------------------------------------------------; DOSSEG .MODEL MEDIUM .386P .STACK 100h .DATA have386dx DB 'You have a 386DX',13,10,'$' have386sx DB 'You have a 386sx',13,10,'$' .CODE mov eax,CR0 ;Read in the CR0 register and eax,0ffefh ;set the 5th bit to 0 mov CR0,eax ;write out modified register to reset CR0 mov eax,CR0 ;Read it back in to see if it changed and eax,00010h ;set register to 0 if 5th bit was zero jnz sxchip ;see if it is sx mov ax,@data ;lets display the dx message mov ds,ax ;set DS to point to the data segment mov ah,9 ;DOS print string function mov dx,OFFSET have386dx ;point to dx message int 21h ;display the message jmp exit sxchip: mov ax,@data mov ds,ax ;set DS to point to the data segment mov ah,9 ;DOS print string function mov dx,OFFSET have386sx ;point to sx message int 21h ;display message exit: mov ah,4ch ;DOS terminate program function int 21h ;terminate the program END --- snip, snip, snip --- George --- theall@rm105serve.sas.upenn.edu Dept. of Economics theall@ssctemp.sas.upenn.edu Univ. of Pennsylvania gtheall@penndrls.upenn.edu Philadelphia, PA 19104
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (12/12/90)
In article <17755@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes: >I wrote: >> >>For what it's worth, I get the following Dhrystone's: >>(Yeah, I know Dhrystone isn't the do all benchmark; anyone got the >>source to Bytes' PC benchmarks?) >> >>16mhz 386SX 20mhz 386DX 25mhz 486 Sun 4/330 >>5000 8000 28000 24000 >> > >Without any further information these benchmarks do not really tell you >anything about the relative performance of an SX to a DX or even a 486 or a >Sun 4. What kind of memory system do the used systems have, are they cached Thank you. Why don't you re-read what I said ("For what it's worth, ....") which means you can put whatever value on it that you want; probably none. All three INTeL machines used 80ns DRAM, the 486 has 128k of 35ns SRAM cache. The INTeL machines under MS-DOS using M'soft C 5.1. and under ESIX SVR3.2 using gcc. The Sun running SunOS 4.x. INTeL machines on ISA bus. Sun is (of course) VME bus. No, the results between SVR3 and MS-DOS weren't exactly the same, but were not materially different. In general, SVR3 results were slightly slower than the DOS results. I also prefaced my post with a disclaimer about Dhrystone. My post was in reponse to a debate about whether an SX could be as fast as a DX under any circumstances. I thought (silly me) that some raw numbers might help resolve the debate. There is a lot more to how fast the machine is than just some memory-only processing. A slow disk drive, or a slow bus arche- tecture, or slow video I/O can bring a screamer to a screaching halt. But then I did ask for the source to the Byte benchmarks, didn't I. -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov You can please all of the people some of the time,
Marc.Brandis@gisatl.FIDONET.ORG (Marc Brandis) (12/13/90)
-- ----------------------------------------------------------------------------- Marc Brandis - via FidoNet node 1:133/411 UUCP: galbp!gisatl!Marc.Brandis INTERNET: Marc.Brandis@gisatl.FIDONET.ORG