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