[Info-vax] OS implementation languages

[Jan-Erik Söderholm]

Den 2023-08-30 kl. 10:53, skrev 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
> 

Note that Rdb does not use RMS for database I/O.

It only use RMS when there is some sequential file involved,
such as when creating a .RBF backup file or an "export" file.
The table "unload/load" probably also use RMS for the .UNL files.

But the whole core database operation does not use RMS, AFAIK...

Jan-Erik.