Very Computer

by **robert a three** » Sat, 17 Feb 1996 04:00:00

No, this is not a continuation of the "All hail Bill..." thread.

I recently got a JPEG/GIF viewer running on Linux (zgv) and
it seemed like it uncompressed JPEGs much faster than I remember.
I have Linux running on an old 386 and Windows 95 running on
my 486 so I decided to race them [fun, eh?!]. I really expected
Linux to [somewhat] equalize the speed between the machines.
However, here's what I found...

[The Machines]
Linux Windows 95
386 DX 40 486 SX 33
128k cache 256k cache
8 Meg RAM 24 Meg RAM
ISA Video & Controller VLB Video & Controller
1 Meg Video RAM 2 Meg Video RAM

[The Race]
63k JPEG = 8 seconds 63k JPEG = 14 seconds
29k JPEG = 5 seconds 29k JPEG = 9 seconds

Everytime I tried it, the 386 w/Linux popped up the
picture in about half the time as the Windows 95 on
the 486. This really surprised me, since the 486 had
more cache, VLB, more video RAM and a whopping 24 Meg
of RAM.

Oh, I realize this isn't a very scientific bench mark.
I just did it for fun and thought someone might enjoy
reading about it.

I'm assuming from this that Linux is way more efficient
than Brand X. One possible flaw in my logic... the
386 DX has a math co-processor. Does the viewing of
JPEGs (or, more to the point, the uncompressing of JPEGs)
use floating point math? If so, the 386 would have an
unfair advantage against the 486 and negate my results
[however dubiuos].

by **Allin Cottrel** » Sat, 17 Feb 1996 04:00:00

> > [The Machines]
> > Linux Windows 95
> > 386 DX 40 486 SX 33
> > 128k cache 256k cache
> > 8 Meg RAM 24 Meg RAM
> > ISA Video & Controller VLB Video & Controller
> > 1 Meg Video RAM 2 Meg Video RAM

> > [The Race]
> > 63k JPEG = 8 seconds 63k JPEG = 14 seconds
> > 29k JPEG = 5 seconds 29k JPEG = 9 seconds
> > [But the] 386 DX has a math co-processor. Does the viewing of
> > JPEGs (or, more to the point, the uncompressing of JPEGs)
> > use floating point math? If so, the 386 would have an
> > unfair advantage against the 486 and negate my results
> > [however dubiuos].

> On the contrary: the internal math co-processor in th i486 should push
> things further into the W95 box's favor!

I don't know whether JPEG decompression calls on the math chip, but I think I'm
right in saying that a 486 SX (as opposed to DX) does not have an internal
co-processor.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

by **David Woodhous** » Sun, 18 Feb 1996 04:00:00

> > I recently got a JPEG/GIF viewer running on Linux (zgv) and
> > it seemed like it uncompressed JPEGs much faster than I remember.
> > I have Linux running on an old 386 and Windows 95 running on
> > my 486 so I decided to race them [fun, eh?!]. I really expected
> > Linux to [somewhat] equalize the speed between the machines.
> > However, here's what I found...

> > [The Machines]
> > Linux Windows 95
> > 386 DX 40 486 SX 33
> > 128k cache 256k cache
> > 8 Meg RAM 24 Meg RAM
> > ISA Video & Controller VLB Video & Controller
> > 1 Meg Video RAM 2 Meg Video RAM

> > [The Race]
> > 63k JPEG = 8 seconds 63k JPEG = 14 seconds
> > 29k JPEG = 5 seconds 29k JPEG = 9 seconds

> > Everytime I tried it, the 386 w/Linux popped up the
> > picture in about half the time as the Windows 95 on
> > the 486. This really surprised me, since the 486 had
> > more cache, VLB, more video RAM and a whopping 24 Meg
> > of RAM.

> > Oh, I realize this isn't a very scientific bench mark.
> > I just did it for fun and thought someone might enjoy
> > reading about it.

> > I'm assuming from this that Linux is way more efficient
> > than Brand X. One possible flaw in my logic... the
> > 386 DX has a math co-processor. Does the viewing of
> > JPEGs (or, more to the point, the uncompressing of JPEGs)
> > use floating point math? If so, the 386 would have an
> > unfair advantage against the 486 and negate my results
> > [however dubiuos].

> On the contrary: the internal math co-processor in th i486 should push
> things further into the W95 box's favor!

But the 486SX doesn't have a maths co-pro! At least, it's disabled.

------------------------------------------------------
__ __ ____ David Woodhouse
| \ / \ \ / | Robinson College,
| | |--| \ / |-- Grange Road,
|_/ | | \/ |___ Cambridge.

------------------------------------------------------

by **David Powel** » Sun, 18 Feb 1996 04:00:00

> > > [The Machines]
> > > Linux Windows 95
> > > 386 DX 40 486 SX 33
> > > 128k cache 256k cache
> > > 8 Meg RAM 24 Meg RAM
> > > ISA Video & Controller VLB Video & Controller
> > > 1 Meg Video RAM 2 Meg Video RAM

> > > [The Race]
> > > 63k JPEG = 8 seconds 63k JPEG = 14 seconds
> > > 29k JPEG = 5 seconds 29k JPEG = 9 seconds

> > > [But the] 386 DX has a math co-processor. Does the viewing of
> > > JPEGs (or, more to the point, the uncompressing of JPEGs)
> > > use floating point math? If so, the 386 would have an
> > > unfair advantage against the 486 and negate my results
> > > [however dubiuos].

> > On the contrary: the internal math co-processor in th i486 should push
> > things further into the W95 box's favor!

> I don't know whether JPEG decompression calls on the math chip, but I think I'm
> right in saying that a 486 SX (as opposed to DX) does not have an internal
> co-processor.

> --
> Allin Cottrell
> Department of Economics
> Wake Forest University, NC

JPEG compression works by taking the image as little 8x8 tiles,
converting the tiles into linear streams by a diagonal zigzag pattern,
performs a Discrete Cosine Transform on the streams, weeding out some
high frequency data, and the huffman compresses the streams. The DCT
stage of the compression I believe would use the coprocessor, which
could be what is making the 386 run faster. (Though, given the
circumstances, I'd love to say that it is Linux)

--

------------------------
David Eric Powell

------------------------

by **Adrian Pfistere** » Wed, 21 Feb 1996 04:00:00

Quote:> I'm assuming from this that Linux is way more efficient
> than Brand X. One possible flaw in my logic... the
> 386 DX has a math co-processor. Does the viewing of
> JPEGs (or, more to the point, the uncompressing of JPEGs)
> use floating point math? If so, the 386 would have an
> unfair advantage against the 486 and negate my results
> [however dubiuos].

The 486 also has a math co-processor.

Adrian Pfisterer.

by **J. S. Jense** » Wed, 21 Feb 1996 04:00:00

> The 486 also has a math co-processor.

> Adrian Pfisterer.

I depends on the 486 level...

--
J. S. Jensen

http://radon.GAS.UUG.Arizona.EDU/~jensenje

by **Brian Stempe** » Thu, 22 Feb 1996 04:00:00

> > I'm assuming from this that Linux is way more efficient
> > than Brand X. One possible flaw in my logic... the
> > 386 DX has a math co-processor. Does the viewing of
> > JPEGs (or, more to the point, the uncompressing of JPEGs)
> > use floating point math? If so, the 386 would have an
> > unfair advantage against the 486 and negate my results
> > [however dubiuos].

> The 486 also has a math co-processor.

> Adrian Pfisterer.

Not the 486sx, which is what he is refering to.

Brian
--

by **Mark Trancha** » Thu, 22 Feb 1996 04:00:00

>> I'm assuming from this that Linux is way more efficient
>> than Brand X. One possible flaw in my logic... the
>> 386 DX has a math co-processor. Does the viewing of
>> JPEGs (or, more to the point, the uncompressing of JPEGs)
>> use floating point math? If so, the 386 would have an
>> unfair advantage against the 486 and negate my results
>> [however dubiuos].

>The 486 also has a math co-processor.

The 386DX, on its own, does *not* have a co-pro. The DX and SX with the 386
mean a completely different thing from the 486. The 386SX has a 16-bit
external bus; the 386DX has a 32-bit external bus. The 486 series all have
32-bit external busses: the SX has no co-pro, whereas the DX has. You need
a 387 to endow FP speed on a 386.

Mark.

p.s. I think IBM's Blue Lightning and other `economy' 486 chips (rarely seen
nowadays) may have a 16-bit external bus.

by **Mark Trancha** » Sat, 24 Feb 1996 04:00:00

>> The 486 also has a math co-processor.

>> Adrian Pfisterer.
>It depends on the 486 level...

True. The 486SX has no co-pro, the DX has a co-pro. The 487 that can be
installed in a 486SX system is just a 486DX that totally takes over from
the SX, if my memory serves me right. I seem to recall Intel charging more
for it than for the DX, so it may have been different: or am I being
naive?

Mark.

by **David Cantre** » Sat, 24 Feb 1996 04:00:00

In article

>> > [The Machines]
>> > Linux Windows 95
>> > 386 DX 40 486 SX 33
>> > 128k cache 256k cache
>> > 8 Meg RAM 24 Meg RAM
>> > ISA Video & Controller VLB Video & Controller
>> > 1 Meg Video RAM 2 Meg Video RAM

>> > [The Race]
>> > 63k JPEG = 8 seconds 63k JPEG = 14 seconds
>> > 29k JPEG = 5 seconds 29k JPEG = 9 seconds

>> > I'm assuming from this that Linux is way more efficient
>> > than Brand X. One possible flaw in my logic... the
>> > 386 DX has a math co-processor. Does the viewing of
>> > JPEGs (or, more to the point, the uncompressing of JPEGs)
>> > use floating point math? If so, the 386 would have an
>> > unfair advantage against the 486 and negate my results
>> > [however dubiuos].

>> On the contrary: the internal math co-processor in th i486 should push
>> things further into the W95 box's favor!

>But the 486SX doesn't have a maths co-pro! At least, it's disabled.

That's OK - the 386DX doesn't have a co-pro either (the copro is the
387)

-- David Cantrell, parttime HTML/VB/Forth techie
fulltime chef, homebrewer, musician, squash player

by **Steve Mo** » Mon, 11 Mar 1996 04:00:00

Quote:>I recently got a JPEG/GIF viewer running on Linux (zgv) and
>it seemed like it uncompressed JPEGs much faster than I remember.
>Linux Windows 95
>386 DX 40 486 SX 33
>8 Meg RAM 24 Meg RAM

>[The Race]
>63k JPEG = 8 seconds 63k JPEG = 14 seconds
>29k JPEG = 5 seconds 29k JPEG = 9 seconds

First, what is the name of the program? I'd really like a fast JPEG viewer on
Linux (all the one's I've seen so far were somewhat slower than what I got in
NT or 95). FYI the fastest I've seen on NT/95 is Polyview 1.7x. Check it out.
It's good (as fast as loading a GIF).

The only discrepency I see with your benchmark is that the 386 is 40MHz while
the 486 is 33MHz. Since most fast JPEG algorithms use integer math (it's
faster, even if you have a floating point chip) I don't think that's a factor.
The 486SX is a 386 chip with 8k of cache. Pure and simple. Cache may not make a
big difference loading JPEGS so it might be a case of higher clock speed and
then of course if your Win95 program uses a different (slower) algorithm...

Steve-

Very Computer

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95

Linux v. Win 95