On 2023-05-04 14:15, Simon Clubley wrote:
> On 2023-05-04, Johnny Billquist <bqt@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

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

On 2023-05-07, Gary Sparkes <mokuba@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.

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

On 2023-05-07, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-05-04 14:15, Simon Clubley wrote:
>> On 2023-05-04, Johnny Billquist <bqt@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.
>

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 ?

Simon.

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

Den 2023-05-09 kl. 14:06, skrev Simon Clubley:
> On 2023-05-07, Gary Sparkes <mokuba@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?

On 2023-05-09, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2023-05-09 kl. 14:06, skrev Simon Clubley:
>> On 2023-05-07, Gary Sparkes <mokuba@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.

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

Den 2023-05-09 kl. 19:49, skrev Simon Clubley:
> On 2023-05-09, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2023-05-09 kl. 14:06, skrev Simon Clubley:
>>> On 2023-05-07, Gary Sparkes <mokuba@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?

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.

On 5/9/2023 8:06 AM, Simon Clubley wrote:
> On 2023-05-07, Gary Sparkes <mokuba@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

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

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.

Den 2023-05-10 kl. 08:36, skrev Jan-Erik Söderholm:
> 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.

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.

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).

--
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.

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...

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

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

On 2023-05-10, Jan-Erik Söderholm <jan-erik.soderholm@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.

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

On 2023-05-09, John Reagan <xyzzy1959@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.

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

On 2023-05-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/9/2023 8:06 AM, Simon Clubley wrote:
>> On 2023-05-07, Gary Sparkes <mokuba@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.

Simon.

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

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

On 5/10/2023 8:23 AM, Simon Clubley wrote:
> On 2023-05-10, Jan-Erik Söderholm <jan-erik.soderholm@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

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

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.

In-correct code can produce different results.

Arne

On 5/10/2023 8:38 AM, Simon Clubley wrote:
> On 2023-05-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> 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.

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

On 2023-05-10, Johnny Billquist <bqt@softjar.se> wrote:
> 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.
>

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.

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