OpenVMS x86-64 V9.2 and Alpha V8.4-2L1 CPU profiles

[mgdaniel]

This originated from a post to the info-WASD mailing list noting the very significant more KERNEL mode used by x86-64 VMS V9.2 https://wasd.vsm.com.au/info-WASD/2023/0077

This also kicked-off a discussion on c.o.v. https://groups.google.com/g/comp.os.vms/c/Eu2eP4Yid7Y

In that post I observe a very significant increase in KERNEL mode usage on X86 V9.2 compared to my Alpha V8.4 and basically ask why? (my uninformed conjecture was memory KESU access via emulation, probably at least that)

Is there someone or somewhere that can explain why the KERNEL mode is the standout in this simple baseline test?

For those who will not read the full test of the above post I'd like to emphasise the ZAP crawl was the most equitable (and easy for me to setup).

ZAP is also used for this KERNEL mode exercise because it results in a
"crawl" of similar portions of underlying files and executables (scripts)
across multiple independent systems and so represents similar profiles of
NETWORK, SYSTEM SERVICE, APPLICATION ACTIVATION AND OTHER ASPECTS of system
behaviour.

[cgrant]

RE: GETSYI in a loop

We have always known that our x86 emulation of PROBE was somewhat of a brute force method that worked but could likely be improved. Over the last few weeks, we have been working on this. (We assume that there is nothing special about GETSYI; it just exhibits typical probing by many system services.)

First, we wrote a C version of LOOP_GETSYI.COM. It does the same 1,500,000 iterations using SYS$GETSYIW in a loop. I'll call these two the .COM and the .EXE versions. The .COM took one minute and 25 seconds to run. The .EXE took 7.8 seconds. After some analysis, tossing around of ideas, and experimental code changes, the .EXE now takes 3.1 seconds! This was done with 1) some streamlining of PROBE itself depending on mode and 2) by stashing away key addresses to allow for eliminating unnecessary probing. It is too late for these changes to be in 9.2-3 in December. They will come later. We continue to investigate this and will likely have more improvements, especially the complete elimination of some PROBEs.

Now back to the .COM. Even with the underlying PROBE changes, the .COM execution time doesn't really change. The culprit here is DCL itself, which could be improved with some rewriting, but we do not intend to address this now.

Clair Grant
VSI Researcher

[mgdaniel]

We have always known that our x86 emulation of PROBE was somewhat of a brute force method that worked but could likely be improved. Over the last few weeks, we have been working on this. (We assume that there is nothing special about GETSYI; it just exhibits typical probing by many system services.)

Excellent news Clair.

Only yesterday I was using OWASP ZAP pushing 3.5M requests through WASD in preparation for the CY25 release.

MONITORing SYSTEM and MODES my, innotek GmbH VirtualBox "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz" with 3 CPUs and 7GB running VMS V9.2-2, x86 system was periodically flat-chat (300%) with KERNEL mode again often prominent (150%+) making me think about the original post again. Serendipity.

It's encouraging that feedback from the forum is noticed and is fed into decision making.

[cgrant]

Breaking news.....

A change to eliminate some probes in the system service dispatcher, in addition to the changes I previously mentioned, improves the .COM by 9%. Not earth-shattering, but enough to reflect another nice step for overall system improvement.

Clair

[arne_v]

Good to see VMS x86-64 being so far that optimization is becoming a key topic.

I assume native build with optimization will be coming soon.

About DCL performance: people doing 1.5 million iterations in DCL need to wait a long time so they have time to reconsider their choice of programming language.

[cgrant]

RE: DCL......exactly why we started by writing the equivalent of the .COM in C. Admittedly, we knew we were headed for PROBE and immediately saw that DCL was in the way. But there is a ton of DCL doing real work, so improving it, even if as a side effect, is beneficial.