What would be involved in moving RMS into kernel mode ?

[Simon Clubley]

If the emulated executive mode is a major reason for the kernel overheads
we are seeing on x86-64 VMS, what would be involved in moving RMS from
executive mode directly into kernel mode ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Johnny Billquist]

On 2023-05-02 15:24, Simon Clubley wrote:
> If the emulated executive mode is a major reason for the kernel overheads
> we are seeing on x86-64 VMS, what would be involved in moving RMS from
> executive mode directly into kernel mode ?

I have a hard time seeing why it would cost very much to deal with the
different modes. I can definitely believe that code hasn't been
optimized in general, though.

Johnny

[Simon Clubley]

On 2023-05-04, Johnny Billquist <b...@softjar.se> wrote:
> On 2023-05-02 15:24, Simon Clubley wrote:
>> If the emulated executive mode is a major reason for the kernel overheads
>> we are seeing on x86-64 VMS, what would be involved in moving RMS from
>> executive mode directly into kernel mode ?
>
> I have a hard time seeing why it would cost very much to deal with the
> different modes.

In which case Johnny, you have no clue about the overheads involved here
when emulating a processor mode in software.

I also suspect you have no clue either about why I keep asking about kernel
overhead on AMD systems and what the significance of that question is.

> I can definitely believe that code hasn't been
> optimized in general, though.
>

At best, that's only a small contribution to the numbers that Mark
is seeing. Also, don't forget that the E/S emulation code is new code,
not ported existing code.

A percentage is a ratio and unless there's any evidence that better
compilers would affect the code running on one side of that ratio much
more than the other side, then the overall percentage should still remain
roughly the same even with better compilers.

I also note that VSI have not responded to Mark's question after the
better part of a week. That's not a good look.

[Gary Sparkes]

> At best, that's only a small contribution to the numbers that Mark
> is seeing. Also, don't forget that the E/S emulation code is new code,
> not ported existing code.
>

Hence it being referred to as potentially unoptimized. First revision and
generation code almost never has a fraction of the performance gains
that future generations will. Then there's also the fact that, well, when trying
to write something correct, you're not worried about performance or optimization
at first - that can come later, so you do it in the cleanest 'correct' way, then get
down into what can be shortened, optimized, restructured, merged, etc.

> A percentage is a ratio and unless there's any evidence that better
> compilers would affect the code running on one side of that ratio much
> more than the other side, then the overall percentage should still remain
> roughly the same even with better compilers.

Compilers aren't magic. Rewriting functions to act specific ways can do
a lot compilers can't.

I just squeezed about 50 seconds of runtime off a current project by
changing the way a specific data set is handled in an internal function -
but outside that function everything still appears and functions exactly the
same - including to already compiled binary code that links/calls it as the
interfaces have not changed.

Anything, of course, that

> I also note that VSI have not responded to Mark's question after the
> better part of a week. That's not a good look.
> Simon.

Not the largest company in the world, and for all we know, they may still be
analyzing the usage/functionality and reported information/reproducing it.

That is, if they've even got the spare cycles to throw at it compared to what's
already on deck from paying customers.

[Hein RMS van den Heuvel]

On Tuesday, May 2, 2023 at 9:24:03 AM UTC-4, Simon Clubley wrote:
> If the emulated executive mode is a major reason for the kernel overheads
> we are seeing on x86-64 VMS, what would be involved in moving RMS from
> executive mode directly into kernel mode ?

Nah, have a link time option to run RMS in user mode! I'm mostly serious.
Moving it to kernel mode you still need to probe the RABs, FABs, XABs and anything those point to.
The protection exec or kernel mode offers is minimal. It makes sure that broken user mode doesn't stomp on data block buffers and corrupts the underlying file impacting downstream usage of those files. Possibly worse, in user mode buggy programs could impact other, shared, users of those files, specially when global buffers are involved.
Well tough luck, write better program, test them better!
Exec mode RMS might help the testing but when is the last time your programs accidently tried to touch an rms buffer and got an accvio?
It (exec or kernel) mode only protects against accidental data corruption (bugs).
It doesn't protect against malicious corruption as anyone with write access can overwrite data.
Regular file protection handles that. Only allow trusted users, or subsystems holding the right identifier, access to critical files.
Admittedly RMS does use CMKRNL for some odd things like borrowing/stealing ENQLM to get out of a tight spot, but in general user mode could be just fine.

fwiw ... back in the day (30 years) ago, while in VMS Engineering I had access to usermode RMS for debugging purposes. It did exists at the time with minimal restrictions. It was rarely - if ever - used. Mostly we worked of crashdumps and 'live' ANAL/SYSTEM to look at the data structures to debug RMS.

Hein.

[Dave Froble]

I have to agree with Hein on this subject. I don't see what inner modes do for
accessing and updating data.

I've got an old database product, similar in some ways to RMS, that runs in user
mode. The only inner modes used are for system wide locks, so that required
privs are not assigned to the users. Works just fine.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 5/4/2023 8:15 AM, Simon Clubley wrote:
> On 2023-05-04, Johnny Billquist <b...@softjar.se> wrote:
>> I can definitely believe that code hasn't been
>> optimized in general, though.
>
> At best, that's only a small contribution to the numbers that Mark
> is seeing.

Sure about that?

The difference between LLVM x86-64 default and -O3 on other platforms
for CPU intensive integer math is a factor 5.

VMS may be very different from "CPU intensive integer math", but
I would not start with an assumption that it would only be a small
contribution.

> A percentage is a ratio and unless there's any evidence that better
> compilers would affect the code running on one side of that ratio much
> more than the other side, then the overall percentage should still remain
> roughly the same even with better compilers.

Are you sure about that?

The WASD download site claims:

<quote>
All the x86-64 object modules have been native-compiled using VSI C
X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2
</quote>

That gives me the impression that the application code (which
must be approx. the code running in user mode) is native compiled
aka optimized. While VMS (code running in inner modes) is not.

Arne

[Arne Vajhøj]

On 5/4/2023 8:15 AM, Simon Clubley wrote:

> I also note that VSI have not responded to Mark's question after the
> better part of a week. That's not a good look.

VSI has to prioritize.

They have ISV's and customers waiting for tools and middleware
to kick off migration projects.

Getting those migration projects underway is important
for VSI.

Based on what has been posted so far then the current
performance on x86-64 is more than fine for the migration
project.

It seems even likely that the current performance on x86-64
will be good enough for production with current applications - if
performance was OK on Alpha and Itanium, then it will be OK
on x86-64.

The day VMS starts competing with Linux and the comparison is
no longer XYZ running on VMS x84-64 vs XYZ running on VMS Alpha
or Itanium but XYZ running on VMS x86-64 vs XYZ running on
Linux x86-64, then the efficiency becomes important for VSI.

So it is an important issue but it is not an urgent issue.

If VSI is lucky then the problem goes away with the native
build of VMS x86-64.

If not then they will need to measure where the time
is actually spent and fix what that is.

Guesses on where that time could be spent make for
great discussions on usenet, but for actually doing
something measuring will be needed.

Arne

[Stephen Hoffman]

On 2023-05-02 13:24:00 +0000, Simon Clubley said:

> If the emulated executive mode is a major reason for the kernel
> overheads we are seeing on x86-64 VMS, what would be involved in moving
> RMS from executive mode directly into kernel mode ?

If you're going to blue-sky this, move RMS and the XQP into a user-mode
process, preferably with zero-copy buffering.

Whether a solitary process or replicated processes would depend on
complexity, aggregate system load, and available cores.

Yeah, I know, I'm making a mach-ery of the existing two-by-two version
of the four-mode design.

But pragmatically, VSI has a few billion projects in the queue ahead of
re-architecting the RMS and XQP giblets.


--
Pure Personal Opinion | HoffmanLabs LLC

[Chris Townley]

I am sure Hein is available

--
Chris

[Steven Schweda]

> I just squeezed about 50 seconds of runtime off a current project

> [...]

As they say on "More or Less", is that a big number?

"50 seconds" out of a minute? An hour? A day? A month? ...

http://www.isthatabignumber.com/

[Gary Sparkes]

50 seconds out of a 57 second runtime for that function. :)

[Jan-Erik Söderholm]

That is not bad, for a single run of that function.

But still, and in line with the question from Steven, did that
function run once each minute? Or once each day/week/month?

[Simon Clubley]

On 2023-05-04, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2023-05-02 13:24:00 +0000, Simon Clubley said:
>
>> If the emulated executive mode is a major reason for the kernel
>> overheads we are seeing on x86-64 VMS, what would be involved in moving
>> RMS from executive mode directly into kernel mode ?
>
> If you're going to blue-sky this, move RMS and the XQP into a user-mode
> process, preferably with zero-copy buffering.
>
> Whether a solitary process or replicated processes would depend on
> complexity, aggregate system load, and available cores.
>
> Yeah, I know, I'm making a mach-ery of the existing two-by-two version
> of the four-mode design.
>

Really ?

I thought you might have been making a mica-ery of the situation. :-)

(After posting, I remembered that the released Prism documents talk about
MICA running its version of RMS in user mode.)

[Simon Clubley]

On 2023-05-04, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> The WASD download site claims:
>
><quote>
> All the x86-64 object modules have been native-compiled using VSI C
> X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2
></quote>
>
> That gives me the impression that the application code (which
> must be approx. the code running in user mode) is native compiled
> aka optimized. While VMS (code running in inner modes) is not.
>

Interesting, thanks. So, maybe yes, or maybe no. Or it could simply be
limitations in the E/S emulation technique coming to light, which
compilers may not be able to do anything about.

It will be nice to get a proper production release of VMS so that we
know for sure, but it doesn't look like that is going to happen this
year. :-(

[Simon Clubley]

Who is he ? :-)

On a more serious note, I've received private email pointing out that
there may be an issue with PPFs if running RMS in user mode.

I also wonder how global buffers might be affected by user-mode RMS.

[Stephen Hoffman]

On 2023-05-05 12:22:56 +0000, Simon Clubley said:

> On a more serious note, I've received private email pointing out that
> there may be an issue with PPFs if running RMS in user mode.

User mode in a different process is (ideally) immune to user mode
shenanigans in a nefarious process, and anything that needs to be
protected within the local process can be in a mode inaccessible to

user mode.

> I also wonder how global buffers might be affected by user-mode RMS.

Either the buffers are mapped and accessible in virtual memory, or not.

(Reducing the numbers of buffer copies has not been a focus for
OpenVMS. There have been previous discussions here concerning the
network stack latency, too.
https://groups.google.com/g/comp.os.vms/c/AAkAPK5_CZ4/m/2RkjDkm2AQAJ )

And there's an open question around how beneficial RMS global buffers
might be in practice, given current SSD transfer speeds are approaching
those of DDR3 SDRAM memory. Upgrades from HDDs to SSDs can hide a whole
lot of app performance issues.

But again, VSI is not in a position to re-architect OpenVMS now, nor in
the forseeable future.

[Hein RMS van den Heuvel]

Chris Townley>> I am sure Hein is available

Nah, happily retired.

On Friday, May 5, 2023 at 6:19:10 PM UTC-4, Stephen Hoffman wrote:
> On 2023-05-05 12:22:56 +0000, Simon Clubley said:
>
> > On a more serious note, I've received private email pointing out that
> > there may be an issue with PPFs if running RMS in user mode.
> User mode in a different process is (ideally) immune to user mode

PPFs would be challenging. Executing RMS in a slave process - dedicated or shared - could solve a lot.
One could perhaps also think of a hybrid solution where usermode is used wherever possible but when for example the PPF flag is seen in the IFI/ISI a dive into the normal exec mode RMS is made .

> > I also wonder how global buffers might be affected by user-mode RMS.
> Either the buffers are mapped and accessible in virtual memory, or not.

Global buffers can be mapped in usermode, the penalty for a bad actor would get magnified as it could kill an unsuspecting other process, which is why I also indicated them as potentially challenging. There is currently also a global buffer lock optimization implemented with system lock. That particular optimization is an enormous win in simple 'get next' processing and cache hits. without that (pre 7.3), every entry into a buffer would at lease convert a lock to up, and down again on exit. with the optimization the system lock guarantees that the right version of bucket data is in the buffer. That is a massive locking (and thus kernel mode or even MPsync time) win.


Hoff> And there's an open question around how beneficial RMS global buffers
Hoff> might be in practice, given current SSD transfer speeds are approaching

Indeed. But that lock optimization I just mentioned is nowadays more important with the caching XFC and faster and faster (caching) IO, for that alone global buffers as a big win.

Hoff> But again, VSI is not in a position to re-architect OpenVMS now, nor in the forseeable future.

Correct.

Also, we just don't know yet where we are whether there is a problem big enough to worry about.
Brute power may well come to the rescue. Let's wait and see the results when X86 VMS is build with optimizing compilers before speculating about the need for a solution.

Some places (C-RTL, COBRTL, SORT) already use their own usermode code avoiding SYS$GET, SYS$PUT for simple unshared sequential files for that very performance reason of avoiding the CMEXEC and PROBES. But for those simple files that overhead is disproportional as they pretty much deal with 1 known buffer of data and a predictable offset in that buffer. Once one gets into indexed file territory the actual work grows a lot often involving multiple buffer visits and buffer searches. With that the the entrance price into the service becomes relatively much less important than work performed for the service.

Cheers,
Hein.

[Jan-Erik Söderholm]

About RMS Global Buffers. What files are these usually used for?
I have got an (maybe wrong) impression that it is mostly indexed
files "databases".

As an example, Rdb is not using RMS for the data/storage. It is
used for some Rdb files like the backup files and "export" files,
but for that I do not see can gain much from faster global buffers...

[Arne Vajhøj]

On 5/6/2023 6:39 AM, Jan-Erik Söderholm wrote:
> About RMS Global Buffers. What files are these usually used for?
> I have got an (maybe wrong) impression that it is mostly indexed
> files "databases".
>
> As an example, Rdb is not using RMS for the data/storage. It is
> used for some Rdb files like the backup files and "export" files,
> but for that I do not see can gain much from faster global buffers...

I am far from an expert in RMS (unlike Hein), but my very basic
understanding is that global buffers work for both sequential
and index-sequential files.

But to provide value in the form of better performance then:
- the same file need to be accessed by multiple processes
- the access need to go through RMS

Which may have been a common scenario 35 years ago, but
not so much today.

An indexed-sequential file being updated by multiple
processes running some Cobol/Basic/Pascal application
designed 35 years ago is probably the most likely
combo to match those criteria.

Arne

[Hein RMS van den Heuvel]

On Saturday, May 6, 2023 at 10:44:58 AM UTC-4, Arne Vajhøj wrote:
> On 5/6/2023 6:39 AM, Jan-Erik Söderholm wrote:
> > About RMS Global Buffers. What files are these usually used for?
> > I have got an (maybe wrong) impression that it is mostly indexed
> > files "databases".

Correct.

> But to provide value in the form of better performance then:
> - the same file need to be accessed by multiple processes
> - the access need to go through RMS

Correct - with write sharing, so not useful for say SYLOGIN.COM.

One more requirement for performance gain through global buffers is repeated access.
You also want to file to remain open as t5he established global buffers are dropped with the last accessor closing it.
One may go as far as creating a helper program to keep files open.

As an example repeated indexed file inserts would go through each index tree top to bottom and the top two layers can often be cached nicely.
With the 7.3 global buffer syslck method even a single process performing sequential gets to a shared file can benefit a lot.
Without global buffer each get would unlock the last record, lock the bucket, locate the next record, lock that, return it, unlock the bucket.
With Global buffers the bucket lock on happens on first entry into the bucket and thus saves almost half the lock activity.

One more easy global buffer win is cluster wide sharing. Whereas with single server access the XFC does a great job caching file, better than Global Buffers really as it is more dynamic, the XFC caching falls apart with cross cluster write shared access any write intend for a file from the 'other' node will flush the buffers for that file everywhere else. The other node then starts building its cache for the file only to tapped on the should for a flush a couple of buffers into the process. RMS Global buffer to NOT have this issue as each buckets is protected from being stale through a per-bucket lock, not per file.

And yes, the classic 'thick', 'cobol' application is a prime candidate but think also about SYSUAF.DAT, RIGHTSLIST.DAT,...

Cheers,
Hein.

[Dave Froble]

On 5/6/2023 10:43 AM, Arne Vajhøj wrote:
> On 5/6/2023 6:39 AM, Jan-Erik Söderholm wrote:
>> About RMS Global Buffers. What files are these usually used for?
>> I have got an (maybe wrong) impression that it is mostly indexed
>> files "databases".
>>
>> As an example, Rdb is not using RMS for the data/storage. It is
>> used for some Rdb files like the backup files and "export" files,
>> but for that I do not see can gain much from faster global buffers...
>
> I am far from an expert in RMS (unlike Hein), but my very basic
> understanding is that global buffers work for both sequential
> and index-sequential files.

I believe that is true.

> But to provide value in the form of better performance then:
> - the same file need to be accessed by multiple processes
> - the access need to go through RMS

Yes.

> Which may have been a common scenario 35 years ago, but
> not so much today.

It's still very common today.

However, global buffers are no longer very helpful. Why? Because of the
caching added to VMS somewhere around V7 or V8.

The CODIS application has one file that just about every process has open. One
would consider such a scenario to benefit from global buffering. However, DAS
(the database product) didn't offer global buffers. When most of your data is
in cache, things can get rather fast. What was observed was performance quite
fast with caching, and a real slog without.

> An indexed-sequential file being updated by multiple
> processes running some Cobol/Basic/Pascal application
> designed 35 years ago is probably the most likely
> combo to match those criteria.

And caching has satisfied that need.

[Gary Sparkes]

On Friday, May 5, 2023 at 4:01:08 AM UTC-4, Jan-Erik Söderholm wrote:
> But still, and in line with the question from Steven, did that
> function run once each minute? Or once each day/week/month?

Constantly. Data ingestion/processing run each loop. Total main
runtime to results is now 20 seconds at most for a single iteration
of the entire program, but it is constantly pulling that data/running
it and updating the display each time. So it was a *massive*
improvement - leaning more on native data structures than the
textbook clean implementation. Can't really say much more
beyond that as it's a current employer project, but just one of
the many examples of optimization that should be thought of
and/or considered instead of just relying on the compiler.

VSI probably has a lot of big easy wins like this coming in the
future, but went with a "textbook" / "robust" POC-level implementation
first. I suspect there are possibly a lot of gains to be had, from
source-level optimization/testing/profiling/etc.

[Gary Sparkes]

On Friday, May 5, 2023 at 8:17:02 AM UTC-4, Simon Clubley wrote:
> It will be nice to get a proper production release of VMS so that we
> know for sure, but it doesn't look like that is going to happen this
> year. :-(
> Simon.

Isn't that what V9.2 is? :)

[Arne Vajhøj]

On 5/6/2023 12:51 PM, Dave Froble wrote:
> On 5/6/2023 10:43 AM, Arne Vajhøj wrote:
>> On 5/6/2023 6:39 AM, Jan-Erik Söderholm wrote:
>>> About RMS Global Buffers. What files are these usually used for?
>>> I have got an (maybe wrong) impression that it is mostly indexed
>>> files "databases".
>>>
>>> As an example, Rdb is not using RMS for the data/storage. It is
>>> used for some Rdb files like the backup files and "export" files,
>>> but for that I do not see can gain much from faster global buffers...
>>
>> I am far from an expert in RMS (unlike Hein), but my very basic
>> understanding is that global buffers work for both sequential
>> and index-sequential files.
>
> I believe that is true.
>
>> But to provide value in the form of better performance then:
>> - the same file need to be accessed by multiple processes
>> - the access need to go through RMS
>
> Yes.
>
>> Which may have been a common scenario 35 years ago, but
>> not so much today.
>
> It's still very common today.

> The CODIS application has one file that just about every process has
> open.  One would consider such a scenario to benefit from global
> buffering.  However, DAS (the database product) didn't offer global
> buffers.  When most of your data is in cache, things can get rather
> fast.  What was observed was performance quite fast with caching, and a
> real slog without.

In the IT world in general data access has moved to client
server models and to relational databases.

I believe that even though VMS still got a large number of
older applications running then it has also at least partly
moved.

> However, global buffers are no longer very helpful. Why? Because of
> the caching added to VMS somewhere around V7 or V8.

>> An indexed-sequential file being updated by multiple
>> processes running some Cobol/Basic/Pascal application
>> designed 35 years ago is probably the most likely
>> combo to match those criteria.
>
> And caching has satisfied that need.

That is a good point.

XFC (VMS 7.3) may have taken care of a lot of the
caching needs.

Arne

[Johnny Billquist]

On 2023-05-04 14:15, Simon Clubley wrote:
> On 2023-05-04, Johnny Billquist <b...@softjar.se> wrote:
>> On 2023-05-02 15:24, Simon Clubley wrote:
>>> If the emulated executive mode is a major reason for the kernel overheads
>>> we are seeing on x86-64 VMS, what would be involved in moving RMS from
>>> executive mode directly into kernel mode ?
>>
>> I have a hard time seeing why it would cost very much to deal with the
>> different modes.
>
> In which case Johnny, you have no clue about the overheads involved here
> when emulating a processor mode in software.
>
> I also suspect you have no clue either about why I keep asking about kernel
> overhead on AMD systems and what the significance of that question is.

And you'd be pretty wrong in your belief. I was maybe the only one
around here that pointed out that it was absolutely possible and no big
issue in running VMS on a hardware architecture that didn't have 4
modes, when pretty much everyone around here claimed it was impossible.

So what overhead are we actually talking about? The different modes are
really nothing more than a question of what protections to have on
pages. The only mode that actually is special is kernel mode. The others
have nothing more special than just a question of what protection to
apply to the pages. There is not much "emulation" about it.

The biggest hit is that if you want that memory protection to apply, you
need to use page tables with the appropriate protections for that mode.
Which you'd probably solve by having multiple page tables, and you
switch which page table to use based on the mode.

So the biggest hit is actually that you need to flush the TLB when
switching modes, which comes with a bit of a cost since the TLB will
need to be repopulated. But that is all done in hardware. So it comes
with a cost, but not a huge one. Depending on the hardware, you might
not even need to flush the TLB, since you are not actually changing any
mappings, just changing the access rights for pages.


I get a feeling you still don't actually understand what the difference
between the modes are, and what impacts this have.

>> I can definitely believe that code hasn't been
>> optimized in general, though.
>>
>
> At best, that's only a small contribution to the numbers that Mark
> is seeing. Also, don't forget that the E/S emulation code is new code,
> not ported existing code.

There is not much emulation, as I point out above. I don't know what you
think is going on, but it sounds like you think there is a lot more in
there than there is (unless VSI did something really strange, which I
doubt).

> A percentage is a ratio and unless there's any evidence that better
> compilers would affect the code running on one side of that ratio much
> more than the other side, then the overall percentage should still remain
> roughly the same even with better compilers.
>
> I also note that VSI have not responded to Mark's question after the
> better part of a week. That's not a good look.

Code running in executive or supervisor would run at the same speed as
code in any other mode. The CPU do not suddenly work in a different way
in any of those modes. The only difference are what protection applies
to memory pages. And that is a setup that happens at the mode switch.
After that, it all runs just as normal.

Johnny

[Johnny Billquist]

On 2023-05-04 22:57, Stephen Hoffman wrote:
> On 2023-05-02 13:24:00 +0000, Simon Clubley said:
>
>> If the emulated executive mode is a major reason for the kernel
>> overheads we are seeing on x86-64 VMS, what would be involved in
>> moving RMS from executive mode directly into kernel mode ?
>
> If you're going to blue-sky this, move RMS and the XQP into a user-mode
> process, preferably with zero-copy buffering.

Hey! Be careful. You are basically describing RSX now... :-D
(RMS and ACPs are in user mode there, and you have zero-copy buffers
both for read and write - with some limitations, of course...)

Johnny

[Simon Clubley]

On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:

> On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>> It will be nice to get a proper production release of VMS so that we
>> know for sure, but it doesn't look like that is going to happen this
>> year. :-(
>> Simon.
>
> Isn't that what V9.2 is? :)

No. Regardless of what the VSI marketing division would have you believe.

VMS is not production-ready until it is built using the final optimised
compilers.

[Simon Clubley]

To read 5,000 records using RMS from a user-mode program requires 10,000
TLB invalidations unless there are any hardware shortcuts available. Have
a think about the implications of _that_ :-)

Fortunately, Intel has such a shortcut available in the form of the PCID
functionality. If used properly, this is supposed to reduce the number
of required TLB invalidations down to a _much_ more reasonable level.

However, until recently, AMD processors did not have PCID support.
Given that VSI have added support for AMD processors, that is why I was
interested in seeing the performance numbers on an AMD box without PCID
support.

The kind of numbers that Mark is reporting on an Intel machine with
PCID support are the kind of numbers I was expecting to see on an older
AMD box without PCID support.

>
> I get a feeling you still don't actually understand what the difference
> between the modes are, and what impacts this have.
>

Actually I do. It's just that I appear to be ahead of you.

>>> I can definitely believe that code hasn't been
>>> optimized in general, though.
>>>
>>
>> At best, that's only a small contribution to the numbers that Mark
>> is seeing. Also, don't forget that the E/S emulation code is new code,
>> not ported existing code.
>
> There is not much emulation, as I point out above. I don't know what you
> think is going on, but it sounds like you think there is a lot more in
> there than there is (unless VSI did something really strange, which I
> doubt).
>

The emulation is the switching out of page tables in the 2 available
hardware modes to emulate the missing executive and supervisor modes.

>
> Code running in executive or supervisor would run at the same speed as
> code in any other mode. The CPU do not suddenly work in a different way
> in any of those modes. The only difference are what protection applies
> to memory pages. And that is a setup that happens at the mode switch.
> After that, it all runs just as normal.
>

Code running in those emulated modes runs at the same speeds _once_ you
are in that mode. However, what about the overhead of getting in and out
of those emulated modes ?

[Jan-Erik Söderholm]

Den 2023-05-09 kl. 14:06, skrev Simon Clubley:
> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
>> On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>>> It will be nice to get a proper production release of VMS so that we
>>> know for sure, but it doesn't look like that is going to happen this
>>> year. :-(
>>> Simon.
>>
>> Isn't that what V9.2 is? :)
>
> No. Regardless of what the VSI marketing division would have you believe.
>

Who said it was VSI that had claimed that?

[Simon Clubley]

|We are excited to announce the availability of VSI OpenVMS V9.2 for x86-64,
|first production release that runs on VMware, KVM, and VirtualBox.

Taken from:

https://vmssoftware.com/about/openvmsx86/

[Jan-Erik Söderholm]

Den 2023-05-09 kl. 19:49, skrev Simon Clubley:
> On 2023-05-09, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>> Den 2023-05-09 kl. 14:06, skrev Simon Clubley:
>>> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
>>>> On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>>>>> It will be nice to get a proper production release of VMS so that we
>>>>> know for sure, but it doesn't look like that is going to happen this
>>>>> year. :-(
>>>>> Simon.
>>>>
>>>> Isn't that what V9.2 is? :)
>>>
>>> No. Regardless of what the VSI marketing division would have you believe.
>>>
>>
>> Who said it was VSI that had claimed that?
>>
>
> |We are excited to announce the availability of VSI OpenVMS V9.2 for x86-64,
> |first production release that runs on VMware, KVM, and VirtualBox.
>
> Taken from:
>
> https://vmssoftware.com/about/openvmsx86/
>
> Simon.
>

OK. I had missed that.
Well, it is not ready for production for us, anyway... :-)
But could be for someone else, I guess. Who is to decide? You, Simon?

[John Reagan]

On Tuesday, May 9, 2023 at 8:08:14 AM UTC-4, Simon Clubley wrote:
> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
> > On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
> >> It will be nice to get a proper production release of VMS so that we
> >> know for sure, but it doesn't look like that is going to happen this
> >> year. :-(
> >> Simon.
> >
> > Isn't that what V9.2 is? :)
> No. Regardless of what the VSI marketing division would have you believe.
>
> VMS is not production-ready until it is built using the final optimised
> compilers.
> Simon.
>

Seems like an arbitrary requirement. Not one that I would use.

Would is surprise you that several pieces of OpenVMS on Alpha and Itanium are
not built with full optimization turned on? For example, several of the language RTLs
are compiled with /OPTIMIZE=LEVEL=2 instead of the default of LEVEL=4. It allowed
me to single step thru the code at the instruction level without losing my hair (well, that
didn't work so well however). I've never bothered to put them back. For code that spends
most of its time waiting on I/Os to complete, the extra optimization is invisible.

[Arne Vajhøj]

On 5/9/2023 8:06 AM, Simon Clubley wrote:
> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
>> On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>>> It will be nice to get a proper production release of VMS so that we
>>> know for sure, but it doesn't look like that is going to happen this
>>> year. :-(
>>> Simon.
>>
>> Isn't that what V9.2 is? :)
>
> No. Regardless of what the VSI marketing division would have you believe.
>
> VMS is not production-ready until it is built using the final optimised
> compilers.

That sounds like a weird criteria to me.

Production readiness should not depend on where the
software build and the level of optimization that is used.

They key metric should be robustness. And based on
what has been posted here and in VSI forum, then VMS 9.2
is pretty solid. There are some reports about problems
in DECWindows and development tools, but the core
OS seems to be rock solid. I don't think I have seen anyone
post about system crashes.

And performance reports indicate adequate performance (as fast
or better than Alpha and Itanium). We do have a suspicion that
performance could be improved a bit by an optimized
native build, but "expected room for improvement" does
not mean "not production ready".

Arne

[Arne Vajhøj]

On 5/9/2023 2:29 PM, Jan-Erik Söderholm wrote:
> Well, it is not ready for production for us, anyway... :-)

Isn't VMS itself production ready for you, but you
are waiting for a bunch of products?

Most important Cobol compiler and Rdb database.

But probably also Python and a few other things.

Arne

[Jan-Erik Söderholm]

Those two. And some other old tools like a user VT menu system
that lacks source code, that we need to replace. We have an initial
meeting on Friday with our infra/platform group to discuss a possible
Alpha/x86 migration for our VMS environment. We'll see...

Our current Python code is V2.7, so I expect some conversion there also.

[Jan-Erik Söderholm]

But my main point was that "production ready" can mean very different
things for different environment and users. It might not as simple as
Simon seems to belive.

[Mark Daniel]

VSI Python 3 (Itanium) is all-but-ready using the WASD PyRTE Jan-Erik.

https://wasd.vsm.com.au/wasd_root/src/python/readmore.html

Should just be a matter of compiling for X86 once available.

Sorry but Python 2 -> 3 is not my specialty.

Nor much else Pythonesque (even though a big fan).

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness or this or that puppy-dog, needs
seriously to examine their critical thinking.

[Jan-Erik Söderholm]

Den 2023-05-10 kl. 10:10, skrev Mark Daniel:
> On 10/5/2023 4:06 pm, Jan-Erik Söderholm wrote:
>> Den 2023-05-10 kl. 01:16, skrev Arne Vajhøj:
>>> On 5/9/2023 2:29 PM, Jan-Erik Söderholm wrote:
>>>> Well, it is not ready for production for us, anyway... :-)
>>>
>>> Isn't VMS itself production ready for you, but you
>>> are waiting for a bunch of products?
>>>
>>> Most important Cobol compiler and Rdb database.
>>>
>>> But probably also Python and a few other things.
>>>
>>> Arne
>>>
>>>
>>
>> Those two. And some other old tools like a user VT menu system
>> that lacks source code, that we need to replace. We have an initial
>> meeting on Friday with our infra/platform group to discuss a possible
>> Alpha/x86 migration for our VMS environment. We'll see...
>>
>> Our current Python code is V2.7, so I expect some conversion there also.
>
> VSI Python 3 (Itanium) is all-but-ready using the WASD PyRTE Jan-Erik.
>
>   https://wasd.vsm.com.au/wasd_root/src/python/readmore.html
>
> Should just be a matter of compiling for X86 once available.
>
> Sorry but Python 2 -> 3 is not my specialty.
>
> Nor much else Pythonesque (even though a big fan).
>

OK. Never have had any IA64 boxes here.

And that is also why cross-compiling can never be part of
anything "production ready" *for us*. For those having access
to IA64 systems it might be different, of course...

[Arne Vajhøj]

On 5/10/2023 2:36 AM, Jan-Erik Söderholm wrote:
> Den 2023-05-10 kl. 01:16, skrev Arne Vajhøj:
>> On 5/9/2023 2:29 PM, Jan-Erik Söderholm wrote:
>>> Well, it is not ready for production for us, anyway... :-)
>>
>> Isn't VMS itself production ready for you, but you
>> are waiting for a bunch of products?
>>
>> Most important Cobol compiler and Rdb database.
>>
>> But probably also Python and a few other things.
>

> Those two. And some other old tools like a user VT menu system
> that lacks source code, that we need to replace. We have an initial
> meeting on Friday with our infra/platform group to discuss a possible
> Alpha/x86 migration for our VMS environment. We'll see...

My expectation is that most current VMS shops are in a process like:
* which of our dependencies are already available on x86-64?
* when will the missing dependencies be available?
* are there and dependencies that will not be available ever? what
can we replace them with?
* when can we start test on x86-64?
* how long a test do we need?

Software availability is everything.

Arne

[Arne Vajhøj]

On 5/10/2023 4:10 AM, Mark Daniel wrote:
> On 10/5/2023 4:06 pm, Jan-Erik Söderholm wrote:
>> Den 2023-05-10 kl. 01:16, skrev Arne Vajhøj:
>>> But probably also Python and a few other things.

>> Our current Python code is V2.7, so I expect some conversion there also.

> Sorry but Python 2 -> 3 is not my specialty.

There are a bunch of know incompatibilities.

Most infamous: / changed from integer division to floating point division.

5/2 is 2 in Python 2 and 2.5 in Python 3.

But also the fact that in 2 both:

print "hi"
print("hi")

work, but only the second work in 3 can cause a lot of (trivial)
changes.

And there are some changes related to strings and unicode
as well.

Arne

[Simon Clubley]

On 2023-05-10, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>
> But my main point was that "production ready" can mean very different
> things for different environment and users. It might not as simple as
> Simon seems to belive.
>

Actually, that's not true. "Production-ready" means exactly one thing,
especially for the kinds of people using VMS:

that the product in question is considered to be finished and has been
through such a robust testing process that you are now willing to trust
the future of your organisation and your organisation's data with it.

There's no way that x86-64 VMS, at this point in its lifecycle, can
meet those criteria, although hopefully that will change rapidly in
the not too distant future.

For one thing, x86-64 VMS is still built using non-optimised compilers.

Any person with any experience elsewhere of the implications of that,
should be asking how many bugs and other issues will emerge once VMS is
built using optimised compilers ?

The good news is that once VMS is built with those compilers, any issues
should be identified and fixed rather quickly. That doesn't change the
fact that VMS still needs to go through this process as a prerequisite to
being considered production-ready.

For another thing, only now are the core layered products starting to
emerge, and they need to go through a couple of cycles to make sure any
basic issues are ironed out. Once again, the good news is that once that
process starts, those issues should be ironed out rather quickly, but
they still need to go through that process. Look at the current basic
issues being reported around the debugger in another thread for example.

x86-64 VMS is well on the road to being production-ready, but IMHO it
isn't there yet.

[Simon Clubley]

On 2023-05-09, John Reagan <xyzz...@gmail.com> wrote:

> On Tuesday, May 9, 2023 at 8:08:14?AM UTC-4, Simon Clubley wrote:
>> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
>> > On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>> >> It will be nice to get a proper production release of VMS so that we
>> >> know for sure, but it doesn't look like that is going to happen this
>> >> year. :-(
>> >> Simon.
>> >
>> > Isn't that what V9.2 is? :)
>> No. Regardless of what the VSI marketing division would have you believe.
>>
>> VMS is not production-ready until it is built using the final optimised
>> compilers.
>> Simon.
>>
> Seems like an arbitrary requirement. Not one that I would use.
>

It's one requirement. There are others, such as the layered products.

Someone with your experience should know what tends to happen when
you turn on optimisation in a code base that was previously developed
with optimisation turned off. :-)

> Would is surprise you that several pieces of OpenVMS on Alpha and Itanium are
> not built with full optimization turned on? For example, several of the language RTLs
> are compiled with /OPTIMIZE=LEVEL=2 instead of the default of LEVEL=4. It allowed
> me to single step thru the code at the instruction level without losing my hair (well, that
> didn't work so well however). I've never bothered to put them back. For code that spends
> most of its time waiting on I/Os to complete, the extra optimization is invisible.
>

That kind of thing I have absolutely no problem with, provided it's
part of the intended design, and provided that any such code is heavily
tested if the optimisation levels are changed.

[Simon Clubley]

On 2023-05-09, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 5/9/2023 8:06 AM, Simon Clubley wrote:
>> On 2023-05-07, Gary Sparkes <mok...@gmail.com> wrote:
>>> On Friday, May 5, 2023 at 8:17:02?AM UTC-4, Simon Clubley wrote:
>>>> It will be nice to get a proper production release of VMS so that we
>>>> know for sure, but it doesn't look like that is going to happen this
>>>> year. :-(
>>>> Simon.
>>>
>>> Isn't that what V9.2 is? :)
>>
>> No. Regardless of what the VSI marketing division would have you believe.
>>
>> VMS is not production-ready until it is built using the final optimised
>> compilers.
>
> That sounds like a weird criteria to me.
>
> Production readiness should not depend on where the
> software build and the level of optimization that is used.
>

$ set response/mode=good_natured

Spoken like a true Java person, who is completely isolated from
the underlying hardware and system-level code. :-)

For a more serious response: In an ideal world, it should not matter.
In the current real world, it most certainly does. Unfortunately.

> They key metric should be robustness. And based on
> what has been posted here and in VSI forum, then VMS 9.2
> is pretty solid. There are some reports about problems
> in DECWindows and development tools, but the core
> OS seems to be rock solid. I don't think I have seen anyone
> post about system crashes.
>

Unoptimised code can make invalid assumptions that are only revealed
when the code is run through an optimiser. Any such problems in VMS
should be discovered rather quickly however once compiled in optimised
mode. It's still a requirement for VMS to go through this process before
it can be considered to be production-ready however.

[Johnny Billquist]

On 2023-05-10 14:23, Simon Clubley wrote:

> Actually, that's not true. "Production-ready" means exactly one thing,
> especially for the kinds of people using VMS:
>
> that the product in question is considered to be finished and has been
> through such a robust testing process that you are now willing to trust
> the future of your organisation and your organisation's data with it.

I would agree with that definition.

> There's no way that x86-64 VMS, at this point in its lifecycle, can
> meet those criteria, although hopefully that will change rapidly in
> the not too distant future.
>
> For one thing, x86-64 VMS is still built using non-optimised compilers.
>
> Any person with any experience elsewhere of the implications of that,
> should be asking how many bugs and other issues will emerge once VMS is
> built using optimised compilers ?

This is utter nonsense. Optimizing code don't suddenly create new bugs.
Unless there are bugs in the toolchain, non-optimized code and optimized
code will produce the same results, but the amount of time and memory
required might differ. Or else the bugs are already there in the
unoptimized code.

Johnny

[Arne Vajhøj]

On 5/10/2023 8:23 AM, Simon Clubley wrote:
> On 2023-05-10, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>> But my main point was that "production ready" can mean very different
>> things for different environment and users. It might not as simple as
>> Simon seems to belive.
>
> Actually, that's not true. "Production-ready" means exactly one thing,
> especially for the kinds of people using VMS:

I suppose there are two kind of people:
- those that assume their view is correct and ignore reality
- that that acknowledge reality and adjust view to match

It is an observable fact that the VMS people here have different
view on the topic.

You can ignore that or acknowledge that.

Arne

[Arne Vajhøj]

On 5/10/2023 8:23 AM, Simon Clubley wrote:

> that the product in question is considered to be finished and has been
> through such a robust testing process that you are now willing to trust
> the future of your organisation and your organisation's data with it.
>
> There's no way that x86-64 VMS, at this point in its lifecycle, can
> meet those criteria, although hopefully that will change rapidly in
> the not too distant future.

It seems rock solid.

And anybody moving to it will (hopefully) test their own
specific application.

Looks pretty good so far.

> For one thing, x86-64 VMS is still built using non-optimised compilers.
>
> Any person with any experience elsewhere of the implications of that,
> should be asking how many bugs and other issues will emerge once VMS is
> built using optimised compilers ?

Given that:
- the native compilers will have been well tested on other
applications when it happens
- the vast majority of VMS code has been build and run with
optimization before
then I would expect a pretty low number.

Arne

[Arne Vajhøj]

Correct code will produce the same result non-optimized and optimized.

In-correct code can produce different results.

Arne

[Arne Vajhøj]

Increasing optimization can cause in-correct code to start
producing bad results.

So building with increased optimization requires test.

But that is not a one time issue.

Every time the LLVM team add new optimizations (or change
existing optimizations) and VSI grab the new LLVM, then
it could in theory cause a problem. And it does require
new test.

That will be the situation as long as VMS exist.

Sure going from unoptimized cross compilers to
optimized (probably not with all optimization enabled
in the first round) is going to be a bigger
change than updating LLVM with new optimizations.
But it is just "bigger" not a different concept.

So I don't think "risk of later optimization triggering
latent bugs" is a good reason for not going to production.

Arne

[Simon Clubley]

If you remove the first two sentences of your reply, you are actually
agreeing with everything I say above and in other posts in this thread.

[Simon Clubley]

Unless the optimiser has a bug in it. :-)

> In-correct code can produce different results.
>

Yes. _Apparently_ working code can suddenly become non-working code when
an optimiser is turned on for the first time or (as you point out in
another reply) when the optimiser is changed.

[Arne Vajhøj]

On 5/10/2023 1:37 PM, Simon Clubley wrote:
> On 2023-05-10, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 5/10/2023 9:23 AM, Johnny Billquist wrote:
>>> On 2023-05-10 14:23, Simon Clubley wrote:
>>>> There's no way that x86-64 VMS, at this point in its lifecycle, can
>>>> meet those criteria, although hopefully that will change rapidly in
>>>> the not too distant future.
>>>>
>>>> For one thing, x86-64 VMS is still built using non-optimised compilers.
>>>>
>>>> Any person with any experience elsewhere of the implications of that,
>>>> should be asking how many bugs and other issues will emerge once VMS is
>>>> built using optimised compilers ?
>>>
>>> This is utter nonsense. Optimizing code don't suddenly create new bugs.
>>> Unless there are bugs in the toolchain, non-optimized code and optimized
>>> code will produce the same results, but the amount of time and memory
>>> required might differ. Or else the bugs are already there in the
>>> unoptimized code.
>>
>> Correct code will produce the same result non-optimized and optimized.
>
> Unless the optimiser has a bug in it. :-)

Johnny's premise was "Unless there are bugs in the toolchain".

Per my understanding the optimization happen in generic LLVM code
aka well tested code so the risk of an optimizer bug should be small.

>> In-correct code can produce different results.
>
> Yes. _Apparently_ working code can suddenly become non-working code when
> an optimiser is turned on for the first time or (as you point out in
> another reply) when the optimiser is changed.

It can happen.

Arne

[John Reagan]

99% of the code is platform-independent and has been compiled and tested with
optimizing compilers on Alpha and Itanium for years. Yes, there is a possibility that
LLVM might have an x86-unique optimization that would expose a latent bug. That can
happen each time we pick up a newer LLVM or even fix a bug. That's why we test.

But back to "what is a production-ready operating system"? You want all the interfaces
to work correctly. A "production-ready platform" would also include available and tested
layered products and compilers. Building the operating system and those LPs with
optimizing compilers is purely a performance issue.