[Info-vax] OS implementation languages

[terry-...@glaver.org]

On Tuesday, August 29, 2023 at 8:29:30 PM UTC-4, Johnny Billquist wrote:
> On 2023-08-29 22:27, bill wrote: 
> > Not really.  VMS has always been notoriously slow with I/O and I assume 
> > that's what Simon was hinting at.
> So? It just means that other systems might achieve higher rate of I/O 
> throughput than VMS on a specific piece of hardware. Nothing prevents me 
> from throwing faster hardware on the problem until I saturate the 
> network, no matter which OS I'm using.

I discovered massive speed differences way back when on a VAX-
11/780 with a TU78 tape drive - $ BACKUP/IMAGE made the tape 
drive go "bloop... bloop... bloop" while a $ BACKUP/PHYSICAL made
the tape drive go "neeeeeeeeeeeeeee" with the same block size.
Same disk, same tape, filesystem overhead.

Since then, both speeds have gotten faster but VMS file-structured
I/O is still WAY slower than the physical hardware. I have an x86-64
system running here with a load of enterprise SSDs that give me a
sustained write performance of 1.8GByte/sec under FreeBSD 13.
I'm running an emulated Alpha (AlphaVM) on it as I haven't heard 
anything from VSI since I (re) registered for their hobbyist program 
quite a few months ago. But from what I've seen, emulated Tru64 is 
a lot faster than VMS under the same AlphaVM release on the same
host OS / hardware.

Yes, that's disk I/O. But I would assume that network paths also have
high overhead (not that it really matters, as real-world high-bandwidth/
high-volume transfers likely involve filesystem data).