From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  1-JUL-1992 08:55:56.52
To:	att!pacbell.com!tandem!hood!bill@ucbvax.Berkeley.EDU
CC:	info-vax@kl.sri.com
Subj:	Re: iozone on vax/vms is slow

att!pacbell.com!tandem!hood!bill@ucbvax.Berkeley.EDU  (Bill Norcott) writes:
> 
> Actually, poor showing on VMS is due to the poor implementation of the write() function
> in VAX C.

	This is absolutely correct. (although the VMS 5.5 version of the
	VAX "C" runtime library may have fixed some of this) the VAX "C"
	read() and write() functions for STREAM_LF files use RMS block
	I/O with 512 byte buffers.  This means that all physical I/O to
	the disk in this case is done 1 block at a time.  Thus, if you
	can get 40 QIOs/sec out of a disk you get at best 20Kb/sec I/O
	throughput.  You might want to try I/O to a FIXED 512-byte record
	file (in which case RMS record I/O is used) and you will see a
	vast improvement (you can add arguments to your file create
	call to make the file FIXED 512-byte).  You may also be able to
	improve the I/O performance on STREAM_LF files considerably by
	specifying a Multi-Block count on the file open/create (again,
	there are arguments you can add to the open or create calls
	to do this).

>	...
>                              I don't have the exact figures anymore, but gcc was on the 
> order of 4-5 times faster than VAX C on writes.    

	This is very unlikely -- GCC on VMS uses the exact same VAX "C"
	runtime and has virtually the exact same performance.  We got
	an astounding improvement on the GCC compiler itself (which uses
	the VAX "C" runtime) by adding "mbc=16" to the file open and
	create calls.
> 
>                           I would consider using asynchronous virtual file I/O calls 
> using $QIO with ASTs to get maximum performance, this is one of the strong points
> of VMS.   However, if you are interested in running portable C applications on VMS,
> be aware that the performance of write() with VAX C is poor.
>

	As mentioned above, by adding a couple of conditional statements
	to your program you can keep it portable and still get performance
	on VMS that is comparable to the performance of very VMS-specific I/O
	code.

David