On Sunday, April 30, 2023 at 12:42:06 AM UTC-4, Volker Halle wrote:
> David Jones schrieb am Samstag, 29. April 2023 um 21:56:27 UTC+2:
>
> thanks for this experiment. It shows the current huge overhead, when introducing kernel mode calls. Let's be fair: VSI is still concentrating on functionality vs. performance for OpenVMS x86-64. So we should wait for the native build of the OS - as indicated by Rob.
>

Since this application only expects a handful of threads, I implemented a user-mode replacement
for pthread_getspecific(). So now, using 2 threads completes the run in 65% of the wall clock
time as the single thread case (with process being charged 130% the CPU time). Using 4 threads
completes in 35% the wall clock time (40% CPU overhead). I don't know if the 40% is scheduler
overheader or memory bus contention or perhaps the power management hardware is varying
the clock speed when 4 cores become active on the laptop.

On 2023-04-28, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2023-04-28 kl. 14:22, skrev Simon Clubley:
>> On 2023-04-28, Volker Halle <volker_halle@hotmail.com> wrote:
>>>
>>> We can continue the VUPS discussion here, but should discuss the KERNEL mode question in the VSI forum.
>>>
>>
>> Why ? The Kernel mode overhead is the real issue that needs discussing,
>> not some artificial CPU speed test.
>>
>
> Why? That should be very obvious.
>
> There is already an ongoing diskussion over at the Forum about this.
> The posts and code posted are much eiser to read.
> Much better thread history.
>
> If the kernel overhead is viewed as "the real problem", it is better
> disussed on the Forum, not here...

That forum post has yet to reveal any meaningful information about
what is going on here and why the kernel mode percentage is so high.

The fact VSI have not yet offered any immediate answers along the lines
of "Oh, don't worry, it's just {X} at play. It will be sorted in a few
months..." is of concern.

I wonder if this is the general level of kernel mode overhead we are now
going to be seeing on x86-64 VMS (and we don't even have any AMD numbers yet).

I do have a related question, but I will ask that in another thread.

Simon.

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

On 2023-04-29, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>
> Any performance numbers for VMS on X86_64 are not *that* interesting until it's
> built with native optimizing compilers.
>
> Native compilers are becoming available, but the build process will take some
> time to convert to a native build.
>
> I do not think (but am not sure) that V9.2-2 (scheduled for near the end of the
> year) would be a native build. Early builds of that version are being done
> with cross compilers.
>

I am surprised at that.

I don't know about anyone else, but I don't really consider this to be even
an early production release until it has been built with native compilers.

Do you have a feeling for when VMS will finally be built using native
compilers ?

Simon.

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

On 5/2/2023 9:30 AM, Simon Clubley wrote:
> On 2023-04-29, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>
>> Any performance numbers for VMS on X86_64 are not *that* interesting until it's
>> built with native optimizing compilers.
>>
>> Native compilers are becoming available, but the build process will take some
>> time to convert to a native build.
>>
>> I do not think (but am not sure) that V9.2-2 (scheduled for near the end of the
>> year) would be a native build. Early builds of that version are being done
>> with cross compilers.
>>
>
> I am surprised at that.

I'd guess that a procedure exists, and it's simple to just queue it up. Since
it's not really "production" without native build and native compilers, as you
state below, no problem.

> I don't know about anyone else, but I don't really consider this to be even
> an early production release until it has been built with native compilers.
>
> Do you have a feeling for when VMS will finally be built using native
> compilers ?
>
> Simon.
>

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

On 5/2/2023 9:30 AM, Simon Clubley wrote:
> On 2023-04-29, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>> Any performance numbers for VMS on X86_64 are not *that* interesting until it's
>> built with native optimizing compilers.
>>
>> Native compilers are becoming available, but the build process will take some
>> time to convert to a native build.
>>
>> I do not think (but am not sure) that V9.2-2 (scheduled for near the end of the
>> year) would be a native build. Early builds of that version are being done
>> with cross compilers.
>
> I am surprised at that.
>
> I don't know about anyone else, but I don't really consider this to be even
> an early production release until it has been built with native compilers.

I am not so surprised over the prioritization.

* Customers desperately need all sorts of applications
for VMS x86-64 to start their migration projects
* the customer impact of VMS being build without optimization
is probably small:
- most customers are just starting up migration projects
and are focused on functionality not performance
- non-optimizing on recent & decent x86-64 HW are
probably in most cases as fast as optimizing on
the 10-25 year old HW being used today in production
* if it turns out that there are bugs in the compilers, then
it is better that it causes an application to crash than
it causes VMS to crash

Of course it need to eventually happen. But getting Cobol/Pascal/Basic
out, getting Java out, getting the "platform type" products out,
maybe support at least one physical server for those with that need
etc. seems more urgent.

Arne