[comp.sys.dec] Comments on relative graphics performance: VAX3100 vs. DEC3100

idallen@watcgl.waterloo.edu (12/03/89)

From: "Ian! D. Allen [CGL]" <idallen>

DEC showed off a 8Mb VAXstation 3100 and a 16Mb DECstation 3100.  The VAX
was running VMS; the RISC was running Ultrix.  Both ran X windows.

What surprised me was the lack of speed of the RISC machine when dealing with
the graphics display.  The VAX (at one-fifth the CPU speed) with its hardware
assist moved pixels around the screen about twice as fast as the RISC.
(I was using the cut/drag feature of dxpaint and the xplaid demo as tests.)

As far as raw CPU power goes, any improvement in CPU on small
applications seems hidden in the usual slowness of the disks.
Starting up applications didn't seem to take any less time, though I
didn't play much to get a better feel for this.  I expect if you were
an engineer running computation-intensive programs, this machine would
seem really fast.  Being a programmer, running compiles and program
loads took about the same time as on our VAX8600.  In fact, compiling
the plaid.c X demo took twice as long on the RISC as on the 8600.  So I
guess I won't expect much RISC improvement for program development.

I read in this group comments to the effect that the graphics hardware
assist in the VAX machines would slow the RISC machine down.  Well, if
that's true, it certainly isn't evident in the two applications I ran.

thompson@batcomputer.tn.cornell.edu (Steve Thompson) (12/03/89)

In article <12528@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu writes:
>From: "Ian! D. Allen [CGL]" <idallen>
>
>DEC showed off a 8Mb VAXstation 3100 and a 16Mb DECstation 3100.  The VAX
>was running VMS; the RISC was running Ultrix.  Both ran X windows.
>
>What surprised me was the lack of speed of the RISC machine when dealing with
>the graphics display.  The VAX (at one-fifth the CPU speed) with its hardware
>assist moved pixels around the screen about twice as fast as the RISC.
>(I was using the cut/drag feature of dxpaint and the xplaid demo as tests.)
>
[etc]

We have both VS3100's and DS3100's. The greatest speed difference that I
have seen between the two machines on floating intensive code is a factor
of 3.3. My biggest application runs 20% faster on the VS3100 than on
the DS3100! Put the two machines side by side and log in on both at the
same time; which comes up with the window first? The VS3100. BTW, the
VS3100 has 8MB, DECwindows, VMS V5.2. The DS3100 has 12MB, UWS 2.0. Both
are diskless machines; the DS3100 served by another DS3100, the VS3100
from a VAX 8250. Before we went to 12MB on the DS3100, it had 8MB, and
one f77 program took 5.5 hours to compile; now it takes 3.5 minutes.
On the VS3100, the same program compiles in 30 seconds.

Steve

rosen@schizo.samsung.com (MFHorn) (12/04/89)

In article <12528@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu writes:

> From: "Ian! D. Allen [CGL]" <idallen>
> 
> DEC showed off a 8Mb VAXstation 3100 and a 16Mb DECstation 3100.  The VAX
> was running VMS; the RISC was running Ultrix.  Both ran X windows.
> 
> What surprised me was the lack of speed of the RISC machine when dealing with
> the graphics display.  The VAX (at one-fifth the CPU speed) with its hardware
> assist moved pixels around the screen about twice as fast as the RISC.
> (I was using the cut/drag feature of dxpaint and the xplaid demo as tests.)

I used to use a VS3100, 8 Meg, 24 Meg swap, RZ23, Ultrix 3.0, pretty
intensively as a big X-terminal, and it almost never even hesitated.

The DS3100s I've used, 16 Meg, 65 Meg swap, RZ55, Ultrix 3.0, build
kernels at least twice as fast, and move pixels around fast enough to
have an animated background (spaceout).  My VS3100 would have choked
trying to do that.

I haven't done much testing than that.

--
Andy Rosen                | rosen@samsung.com       | "I got this guitar
Samsung Software America  | rosen@samsung.UUCP      |  and I learned how
One Corporate Drive       | (508) 685-7200          |  to make it talk"
Andover, MA 01810         |                         |    -Thunder Road

marbru@auto-trol.UUCP (Martin Brunecky) (12/05/89)

In article <12528@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu writes:

> From: "Ian! D. Allen [CGL]" <idallen>
> 
> What surprised me was the lack of speed of the RISC machine when dealing with
> the graphics display.  The VAX (at one-fifth the CPU speed) with its hardware
> assist moved pixels around the screen about twice as fast as the RISC.
> (I was using the cut/drag feature of dxpaint and the xplaid demo as tests.)
>
	I have DS3100/24MB/RD54/2*RZ23/Ultirx and VS311/8MB/2*RZ23/VMS
        side by side.
	We'v run several benchmarks (Xstones...), but I refuse to use any
	such toys to measure performance. In my opinion, benchmarks measure
	how fast you can benchmark - which has nothing to do with the real
	application life.

	Now, for most of the operations AND applications I am running on
	both machines, I would put DS3100 at 2-3 times faster than the VAX.
	And for many (not all) operations 2 times faster than SPARCstation 1.
	Window creation speed, popup appearance, vector drawing speed etc.
	Plus any application startup - but this has nothing to do with HW
	[VMS development is famous for creating image startup overhead].
	Somebody has mentioned the login speed here. My login starts about 6
	applications on both machines - and it feels like 100:1 - the VAX
	login takes for ever. Rebooting the machine even worse (my VAXstation
	boots of it's own disk, but it is a member of a large cluster).

	For the particular case above, i.e. "moving pixels around the screen",
	we must consider two issues:

	1) VAXstation GPX hardware is fairly fast in doing on-screen bit-blts.
	   The DECstation does it in SW, and then the speed depends on
	   number of bitplanes (color/mono). But I can hardly believe that
	   the difference would be twice. My figure dragging does not
	   feel like that (but - no measurement done).

	2) Any "moving pixels around" controlled by the client requires
	   some form of pointer tracking. Either motion events, motion-hint
	   or XQueryPointer (one discussion on this conference concluded
	   that the combination of motion-hint/XQueryPointer is the best).
	   From my experience, this is the critical area of any "moving
	   around". The roundtrip delay or motion event filtering/rejection 
	   overhead is more important than bit-blt speed, at least for
	   small rasters - such as 100x100 pixels.
	   Now, the VMS VAXstation uses shared memory transport, the DECstation
	   seems to use sockets. My feeling is that the VAXstation roundtrip
	   is much faster than DECstation (no measurement done).

	The main thing that worries me about DECstation is the lack of
	shareable libraries and file mapping capabilities (maplock).
	The MIPS/RISC code is larger than that for CICS machines. And without
	code sharing, I need mega and megabytes of disk storage ( just
	note you need 300MB drive for Ultrix, and a 100MB drive for full VMS ).
	Disks are cheap .... but the disk channel speed does not seem to
	follow the RISC CPU performance curve. Without shareable libraries
	you must stuff your DECstation with 24MB of memory to avoid any
	swapping, and you may still feel I/O bottleneck.

-- 
###############################################################################
Martin Brunecky, Auto-trol Technology Corporation,
12500 North Washington Street, Denver, CO-80241-2404
(303) 252-2499                                        ncar!ico!auto-trol!marbru