blinn@renko.DEC.COM.UUCP (02/14/87)
One reason use of the RAM pseudo-disk in VMS is neither recommended nor
supported for customer use by Digital is that it ties up physical memory
that might otherwise be used for general purposes and shared by many
processes.
While it's true that some applications can be easily accelerated by the use
of RAM pseudo-disk, there are likely to be other applications in the system
whose performance is negatively impacted. (Of course, if you've got lots
more memory on the system than you need to hold all the working sets for
all the active processes, then this may not be an issue for you; but why
did you buy so much memory? :^)
The applications that are most easily sped up by using RAM pseudo-disk are
those that are maintaining "scratch files" of data on disk. In many cases,
these are old applications that were moved onto virtual memory systems from
an older fixed-memory allocation machine (such as a PDP-11 or IBM S/360),
and were written to use "scratch files" because there was no way to get the
needed data all into memory at the same time. Such applications can often
be sped up even more by recoding them to use "in-memory" arrays in place of
scratch files; then VMS will use virtual memory management to keep the
actively used data buffered in real memory. If you use a RAM pseudo-disk,
both actively used and inactive data will be kept in real memory. Of
course, you have to set the memory management parameters for the system
and/or the process correctly, or you'll prevent VMS from doing anything
intelligent with the available physical memory.
It's an often forgotten truth that the greatest performance gains can
usually be attained by rethinking the algorithm, rather than by tuning some
small part of the application code. Once you've got the right algorithm,
then you worry about squeezing the last increment of performance out of it.
In a virtual memory environment (such as that provided by VMS and most
modern computer systems), programming techniques that make extensive use of
I/O intensive scratch files on disk are usually the wrong algorithm, and
are almost always the wrong implementation even when the algorithm is
right.
Regards,
Tom
Dr. Thomas P. Blinn
U. S. Volume Operations
Digital Equipment Corporation
Two Iron Way -- MRO3-3/R18
Marlboro, Mass. 01752-9003
Internet: blinn%furilo@decwrl.dec.com
Easynet: FURILO::BLINN
Usenet: {decvax,ucbvax,allegra}!decwrl!furilo.dec.com!blinn
Voice: (617) 467-5562
Note:
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.