[Info-vax] OS implementation languages

[Johnny Billquist]

On 2023-08-30 10:04, terry-... at glaver.org wrote:
> 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).

Which still means, in the end, that VMS do not have a limitation on the 
speed of I/O as such, and a question of "how fast can VMS push bits" is 
really just a question of how fast your hardware is.

But your observation also raise another good point. I/O is sortof slow 
in VMS, but it's not the actual I/O that is the main problem, but RMS. 
The overhead here is pretty massive compared to something stupid like Unix.

Not sure how easy it is to dodge RMS under VMS. In RSX, you can just do 
the QIOs to the ACP yourself and go around the whole thing, which makes 
I/O way faster. Of course, since files still have this structure thing, 
most of the time you are still going to have to pay for it somewhere. 
But if you are happy with just raw disk blocks, the basic I/O do not 
have near as much penalty. Admitted, the ODS-1 (as well as ODS-2) 
structure have some inherent limitations that carry some cost as well. 
So you could improve things some by doing some other implementation on 
the file system level.
But mainly, no matter what the file system design is, you are still 
going to have the pain of RMS, which is the majority of the cost. And 
you'll never get away from this as long as you use VMS.

It's like if you were to always access all files in Unix via BDB. If 
people were to do that, the numbers on Unix systems would also look very 
different.

   Johnny