Article View: comp.sys.ibm.pc.hardware
Article #19783SKIP
From: u5775949
Date: Mon, 11 Jan 1993 03:08
Date: Mon, 11 Jan 1993 03:08
70 lines
3120 bytes
3120 bytes
In article <1993Jan9.172511.7360@infonode.ingr.com>, bbrown@infonode.ingr.com (Bailey Brown) writes:
>
> I was thinking about upgrading my 386DX/33 with a cheap 486DX/33
> motherboard. The two things I wanted to go faster were games
> (had to turn off clouds in Comanche Maximum Overkill) and
> JPEG. So I ran some tests on a friend's Taiwanese 486DX/33
> of unknown chipset:
>
> 386 - Swan 386DX/33, Micronics MB with either 32 or 64K cache (I'm ashamed
> to admit I'm not sure which, salesman said 32K, magazine review said
> 64K, manual says both are possible), Intel cache controller,
> 8MB ram, Pheonix bios
>
> 486 - noname 486DX/33, Taiwanese MB of unknown chipset, 256K external cache,
> 16MB ram, AMI bios
>
> Tests:
>
> Tests were run on bare dos 5.0 with minimal stuff in config files:
>
> I used the Independent JPEG Group vesion4 jpeg code, compiled with
> the Intel 386/486 C Codebuilder (32bit extended dos) compiler.
> The jpeg stuff is not disk bound, and besides, both systems have
> comparatively fast IDE drives. Timing was done with a stopwatch.
> lake2.gif is 630x422x256.
>
> cjpeg -Q 80 lake2.gif:
>
> 386: 15.0 sec
> 486: 29.7 sec
Something I found recently was that some of the chipset setup
programs initialise memory waitstates and clock rates on the
conservative side of things when using the "QUICK" setup or
"SET DEFAULTS". In my 386DX 33MHz machine the AMI bios setup
could be modified to go much faster provided the correct RAM
chips and bus hardware is used. Maybe the two machines
your comparing could be optimised? Also I noticed that some
assembler instructions run slowerrr or a 386 than a 286 ?"{
- could this be happening on you particular code for the 486??
good luck , mark harrison
>
> djpeg lake2.jpg:
>
> 386: 23.3 sec
> 486: 47.3 sec
>
> The other benchmark results were more reasonable, but these
> were canned benchmarks, not real-world tests.
>
> Norton 4.0 cpu index:
>
> 386: 42.7
> 486: 54.2
>
> Norton 5.0 cpu index:
>
> 386: 35.4
> 486: 72.1
>
> Does anyone have a clue as to why the 486 was twice as slow on the jpeg
> stuff? I know the Intel cache controller on my 386 uses posted writes for
> 0ws writes 100% of the time, and the 486's external cache may be
> write-through, but shouldn't the internal writeback cache in the 486 buffer
> the effects of this, if the 486's external cache is indeed write-through.
>
> ------------
> Bailey Brown "Above all else, confusion reigns."
> Intergraph Corporation
> bbrown@casca.b11.ingr.com Procol Harum
Technical Details
Message-ID:
<1993Jan11.140855.4406@ucsvc.ucs.unimelb.edu.au>Path:
arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!u5775949References:
<1993Jan9.172511.7360@infonode.ingr.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!u5775949 From: u5775949@ucsvc.ucs.unimelb.edu.au Newsgroups: comp.sys.ibm.pc.hardware Subject: SKIP Message-ID: <1993Jan11.140855.4406@ucsvc.ucs.unimelb.edu.au> Date: 11 Jan 93 14:08:55 +1100 References: <1993Jan9.172511.7360@infonode.ingr.com> Organization: The University of Melbourne Lines: 70