Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!samsung!uakari.primate.wisc.edu!ames!ncar!ico!auto-trol!marbru From: marbru@auto-trol.UUCP (Martin Brunecky) Newsgroups: comp.sys.dec Subject: Re: Comments on relative graphics performance: VAX3100 vs. DEC3100 Message-ID: <465@auto-trol.UUCP> Date: 5 Dec 89 15:48:20 GMT References: <12528@watcgl.waterloo.edu> Reply-To: ncar!ico!auto-trol!marbru (Martin Brunecky) Distribution: comp Organization: Auto-trol Technology, Denver Lines: 63 In article <12528@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu writes: > From: "Ian! D. Allen [CGL]" > > 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