08-Jan-2010

How much faster is FAST I/O?

Quite some time ago, I was asked how much better FAST I/O is than say, accessing the data via reading blocks with $QIOW. I didn't know at the time, and if you've spent any time in this game, you'll know that "I don't know" is an unacceptable answer. The correct response is "I'll find out!".

Here are the results of reading a sequential file block by block with $IO_PERFORMW() and $QIOW(). The test file is a 500,000 block file marked no_caching residing on a privately mounted disk served up by an EVA 8100. Two programs access the file with the QIO/ACP interface, and then perform 500,000 reads of 512 bytes on the file to completely read the file. Note that the EVA is allowed to cache the disk (for both programs) so we should eliminate a lot of disk latency from the timing after the first couple of runs. LIB$INIT_TIMER() and LIB$SHOW_TIMER() are used to record results, and the average of ten alternate runs is calculated.

The average elapsed time for FAST I/O verses QIO is 51.3 verses 52.0 seconds.

The average CPU time for FAST I/O verses QIO is 3.63 verses 5.01 seconds.

As we expect, significant time is spent reading the data from the disk, and the difference between the two averages is less than 1.4% But the difference in CPU time is marked at 27.6%

So in conclusion, if you need to do extensive non-record I/O to a file (or you're looking to implement your own file structure), and you can coerce the systems manager into giving you the VMS$BUFFER_OBJECT_USER identifier, you can save significant CPU time by using the Fast I/O services.

Posted at January 8, 2010 7:44 PM
Tag Set:
Comments

Did you try doing some larger I/O requests?

IIRC Guy Peleg did some tests with a file copy program which used FASTIO and had positive results

Posted by: Ian at January 9, 2010 9:26 PM

Nope, just 512 byte reads. But I think a 27% speedup certainly counts as a "positive result".

Posted by: Jim Duff at January 10, 2010 9:12 AM

It makes sense that the main thing that is improved is CPU time however I think elapsed time is often more important. I suspect that the improvement in elapsed time may be better with larger I/O requests.

Posted by: Ian Miller at January 14, 2010 9:02 PM

Comments are closed