NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/mac/misc/14928

Text File | 1992-08-16 | 6.0 KB | 130 lines

Newsgroups: comp.sys.mac.misc
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!nntp-server.caltech.edu!hyongel
From: [e-mail] (Hyong Chol Lee)
Subject: Re: Information on: The IIvi, IIvx, and Performa 600
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: bartman
Organization: California Institute of Technology, Pasadena
References: <[e-mail]>
Date: Mon, 17 Aug 1992 01:30:25 GMT
Lines: 117

[e-mail] () writes:

>Someone emailed to me (Liam Breck):
>> in comp.sys.mac.misc you write:
>> > The IIsi's only advantages are slightly better CPU speed (not a big
>> > enough difference to notice in real time use, but you will notice the
>> > disappointing screen redraw speed) and the ability to plug in Nubus
>> > cards, again, not an issue because the LCII is a very popular machine,
>> > so there are a lot of cards for its PDS (processor direct slot).
>>
>> You want to justify this? The si uses a 32 bit bus, not a 16 bit bus, so is
>> about twice as fast. Same reason an SE/30 is twice as fast as an LCII. Also
>> an LCII has max memory of 10MB. That doesn't leave much room for expansion.
>> I have 8MB on my SE/30 right now and plan to go to 20MB in a month or so.
>> I'd be pissed off if my machine maxed out at 10MB.

>This is a common misconception.  Actually, the IIsi is about 28%
>faster, which is not enough to notice in most real-time applications.

from Speedometer 3.06

test             iisi        lc

cpu            5.4        3.3
b/w graphics          6.1         4.3
math (integer+f.p)    6.1        3.8

dhrystone        5.0        2.2
sieve            6.9        4.4

From the numbers above, it would seem that the iisi is between 50% and 100%
faster than an lc. The lcii is about 10-20% faster than an lc, due to the fact
that an 030 has an onboard mmu and therefore takes one less cycle to execute
most instructions than the 020 in an lc. --> iisi is between 25% and 70% faster
than an lcii at most things. I don't know where this 28% number came from.

>processor speed beetween the two machines -- 16MHz vs. 25MHz.  The

The iisi runs at 20 Mhz. That would make a 25% difference, if it weren't for
the fact that the lcii has a 16 bit data bus vs. the 32 bit data bus on the
iisi. Although the effect halving the data bus is difficult to predict in
general, it will range from 0% (entire program in the 020 cache - not likely)
to reduction of relative preformance by 1/3-1/2 (for programs which have 0
cache hits - also not very likely). In general, the lcii seems to run at 2/3
- 3/4 the speed of an se/30, which also runs an 030 at 16 Mhz with vrams. So,...
it seems that halving the data bus (the se/30 has a 32 bit data bus) reduces
general performance by 1/4 to 1/3. That would mean that the lcii should be
about 1/2 the speed of a iisi (030 running at 20 Mhz w/ 32 bit data bus). The
exception is something like 8-bit graphics, which should run about the same
speed on both machines due to the fact that Apple decided to use drams on the
iisi as video memory instead of using vrams as they should have. The slowdown
caused by the video contention in the video memory of the iisi is about the
same (apparently) as slowing the 030 down to 16 Mhz and putting it on a 16 bit
bus with no memory contention (as in the lcii with vrams).


>*IIci* is something like twice as fast as the LCII since it's clock
>speed is 33MHz.

The iici runs at 25 Mhz and is about twice as fast as an lcii, even with the
memory contention in the video memory.

>The bandwidth of the memory bus is really not
>critical in personal computers, 'cause other bottlenecks hold things
>up before the bus width does.

If the memory bandwidth of a machine was not significant, cache cards wouldn't
help. As it is, they do - so memory bandwidth is important. An 030 has a minimum
2 clock cycle memory access time. Most macs (including the lcii and iisi) have
a main memory access time of 5 cycles. The iisi compensates for that a bit by
having burst cycles where it reads 4 32-bit words in 11 cycles (5 cycles for the
first word and 2 cycles each for the other 3). The lcii doesn't have this
feature (I think that is because burst reads require a 32 bit data bus). The
most convincing argument that memory bandwidth is important is that an se/30 is
about 50% faster than an lcii, even though the clock speeds are the same.


  For instance, the 80386 is only 4%
>faster than the 80386sx, which has a 16-bit external memory path.

4% faster doing what? With which program(s). I seriously doubt that the 386sx
is 96% of the speed of a 386dx in most cases.

>It's the same in the case of the Macs; you'll find that the original
>Mac II is only 4% faster than the original LC (both 020s at 16MHz).

I seem to remember the mac ii being faster than that, but I don't have any
numbers in front of me ..
.
>A really critical issue, though, is screen redraw time, since most
>real-time apps (word processors, drawing apps, the finder, etc.)
>redraw the screen a lot.  The LCII uses the latest Apple on-board
>video standard, which includes dedicated, dual-ported VRAM.  The same
>stuff that the Quadras use, only pared down for the LCII.  It's very
>fast compared to using the main memory for video (the IIsi and IIci do
>this).  You can speed up video on the latter machines by making your
>RAM cache huge, but that's another subject, see one of the columns in
>the current MacWorld (sorry, forget which one) for more info.

This is true, but the lcii is hobbled by a 16 bit data bus. In 8-bit (256 color)
mode, the lcii is about as slow as a iisi. For b/w, 4 color, and 16 color modes,
the lcii is significantly slower, since the slowdown in the iisi's video tracks
the number of colors on screen.

>Another point about video...  Since the LCII can use a low cost VGA
>monitor (I got a Trinitron screen for $350) it really lets you save on
>the monitor.  To get the same quality on a IIsi, expect to shell out
>the bucks!

Unfortunately, this is very true!

>Liam Breck     [e-mail]

            - hyong
[e-mail]