>We recently made the move to UNIX (Sun Workstation) from VMS (Vax 6430). GCG
>runs MUCH better on the UNIX workstation. To further substantiate this I
>called GCG Inc. and asked which platform provided the best performance. The
>immediate reply was UNIX. Even VMS on an Alpha is supposedly not as
>resposive as the UNIX/Sun set-up. Apparently, VMS just isn't as speedy as
>UNIX in file handling and i/o.
There is a grain of truth to this, many of the higher level IO routines on
VMS are a bit slower than on Unix. This shows up mostly when you are
rapidly manipulating hundreds or thousands of files. (In any case, this
too will change soon when the new log based VMS file system comes out.)
However, if you think about it for more than a few seconds, you'll realize
that the low level disk read routines in any operating system are little
affected by what goes on above them, and so for the same hardware should
run at the same speed regardless of OS.
Here is some experimental evidence to suggest that this is true. I didn't
have two identical machines, but I did have two AXP's with fairly similar
disks that could be set to IO bound tasks. The tests here are designed to
measure simply how fast the system can read a 100 Mb file, which is a fair
approximation for what goes on during a Stringsearch or BLAST. I didn't
test disk write rates - these tend not to be rate limiting for many
programs.
The following VMS disk read benchmark was suggested by one of the folks on
COMP.OS.VMS. It does go through RMS, but at close to maximum efficiency.
A few percent could be shaved off by doing the IO at a level below RMS
(which is not difficult to do - although it isn't at all portable either!)
$ create/fdl=sys$input mscdisk:[000000]100mb.dat
FILE; ALLOC 204800; BEST_TRY yes; RECORD; FORMAT FIXED; SIZE 8192
^Z
$ set file/end mscdisk:[000000]100mb.dat
$ set rms/seq/buf=10/block=64
$ search/stat/win=0 mscdisk:[000000]100mb.dat "gobblygook"
Files searched: 1 Buffered I/O count: 4
Records searched: 12800 Direct I/O count: 3200
Characters searched: 104857600 Page faults: 21
Records matched: 0 Elapsed CPU time: 0 00:00:20.41
Lines printed: 0 Elapsed time: 0 00:00:35.86
No strings matched
Or about 2.9 Mb/second. This was run on our VMS 6.1, 2100 A500MP using the
internal SCSI controller on our 2100 to talk to an RZ28 in the Storageworks
enclosure.
I then FTP'd that exact same file (binary mode) to our 200 4/166 Digital
Unix 3.2 system (which uses RZ29's), and did:
% grep gobblygook 100mb.dat
Which took 3 minutes, 17 seconds, egrep took 3:55, fgrep took 31 seconds.
% cp 100mb.dat /dev/null
also took 31 seconds, suggesting that this is close to the maxium read
speed on Digital Unix for the 200 4/166.
So there is at most a minor difference between the two OS's for the
quantity measured (here Unix was 12% faster that VMS.) It wouldn't be wise
to make too much of this small difference since since the Unix system was
completely empty while the VMS one had 5 users logged on, the two systems
were using different types of disks, the VMS test was though RMS rather
than one or two levels below it, and so forth.
In summary, and unless somebody can supply further proof to the contrary,
I'd have to assert that the differences between the disk READ rates on VMS
and Unix for similar hardware are negligible - given properly designed
software (note grep vs. fgrep vs. search.)
Regards,
David Mathog
mathog at seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
