As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.

First, OpenSSH, which suffers greatly from not being built for VMS with x86 assembler optimizations. Curiously, the 4096 bit RSA test was nearly 60% faster when run on the Linux host rather than inside my Ubuntu Server VM. Since it's the same version of OpenSSH, and the other speed tests gave identical results between bare metal and Linux VM, I don't know what to attribute that to.

Here are the VMS and Linux speeds, followed by the ratio of Linux to VMS (higher scores are better). All results are the average of 3 runs.

rsa 4096 bits sign/s: VMS = 11.8, Linux = 233.3 (19.77x)
rsa 4096 bits verify/s: VMS = 852.4, Linux = 15021.5 (17.62x)

(Following numbers are in 1000s of bytes per second processed)

sha256, 16 bytes: VMS = 768.04k, Linux = 77014.12k (100.27x)
sha256: 64 bytes: VMS = 2965.24k, Linux = 200264.14k (67.54x)
sha256: 256 bytes: VMS = 10837.12k, Linux = 421229.97k (38.87x)
sha256: 1024 bytes: VMS = 32547.53k, Linux = 577376.77k (17.74x)
sha256: 8192 bytes: VMS = 78364.77k, Linux = 644813.20k (8.23x)
sha256: 16384 bytes: VMS = 87204.63k, Linux = 649131.38k (7.44x)

sha512 , 16 bytes: VMS = 770.86k, Linux = 57818.49k (75.01x)
sha512 : 64 bytes: VMS = 3081.86k, Linux = 231261.67k (75.04x)
sha512 : 256 bytes: VMS = 11691.87k, Linux = 469829.08k (40.18x)
sha512 : 1024 bytes: VMS = 40253.92k, Linux = 770282.03k (19.14x)
sha512 : 8192 bytes: VMS = 140511.75k, Linux = 955133.22k (6.80x)
sha512 : 16384 bytes: VMS = 171268.94k, Linux = 971181.22k (5.67x)

AES-128-GCM, 16 bytes: VMS = 52389.06k, Linux = 731482.29k (13.96x)
AES-128-GCM: 64 bytes: VMS = 64247.33k, Linux = 1867970.54k (29.07x)
AES-128-GCM: 256 bytes: VMS = 70553.48k, Linux = 3713979.67k (52.64x)
AES-128-GCM: 1024 bytes: VMS = 72296.92k, Linux = 6027351.62k (83.37x)
AES-128-GCM: 8192 bytes: VMS = 72317.90k, Linux = 7630128.89k (105.51x)
AES-128-GCM: 16384 bytes: VMS = 72337.10k, Linux = 7799369.48k (107.82x)

AES-256-GCM, 16 bytes: VMS = 47903.51k, Linux = 634127.50k (13.24x)
AES-256-GCM: 64 bytes: VMS = 57722.18k, Linux = 1750850.44k (30.33x)
AES-256-GCM: 256 bytes: VMS = 62676.83k, Linux = 3131857.16k (49.97x)
AES-256-GCM: 1024 bytes: VMS = 63982.17k, Linux = 4711443.18k (73.64x)
AES-256-GCM: 8192 bytes: VMS = 64375.58k, Linux = 5595369.92k (86.92x)
AES-256-GCM: 16384 bytes: VMS = 64263.75k, Linux = 5673393.94k (88.28x)

ChaCha20, 16 bytes: VMS = 76456.19k, Linux = 534685.07k (6.99x)
ChaCha20: 64 bytes: VMS = 100830.84k, Linux = 970432.25k (9.62x)
ChaCha20: 256 bytes: VMS = 109619.82k, Linux = 2026910.42k (18.49x)
ChaCha20: 1024 bytes: VMS = 112586.76k, Linux = 4098876.65k (36.41x)
ChaCha20: 8192 bytes: VMS = 113955.06k, Linux = 4287163.43k (37.62x)
ChaCha20: 16384 bytes: VMS = 114424.67k, Linux = 4303112.74k (37.61x)

ChaCha20-Poly1305, 16 bytes: VMS = 56328.32k, Linux = 401319.24k (7.12x)
ChaCha20-Poly1305: 64 bytes: VMS = 83036.66k, Linux = 768498.64k (9.25x)
ChaCha20-Poly1305: 256 bytes: VMS = 90210.62k, Linux = 1564155.33k (17.34x)
ChaCha20-Poly1305: 1024 bytes: VMS = 93680.18k, Linux = 2820100.89k (30..10x)
ChaCha20-Poly1305: 8192 bytes: VMS = 94924.99k, Linux = 2998130.64k (31..58x)
ChaCha20-Poly1305: 16384 bytes: VMS = 95001.36k, Linux = 3010321.70k (31.69x)

I ran the same two PerlBench tests that Phoronix uses. Avg score from 1 run, in sec, plus ratio of VMS time / Linux time.

app/podhtml.b: VMS = 4.246, Linux = 0.09854 (43.09x)
startup/noprog.b: VMS = 0.04891, Linux = 0.0008568 (57.09x)

Now, PHPBench scores, average of 3 runs (higher is better):

VMS = 119269.3, Linux = 998728.0 (8.374x)

For PostMark, I used the Phoronix test config:

$ type benchmark.pmrc
set transactions 250000
set size 5120 524288
set number 500
run
quit
$ postmark benchmark.pmrc

Time:
2317 seconds total
2311 seconds of transactions (108 per second)

Files:
125608 created (54 per second)
Creation alone: 500 files (125 per second)
Mixed with transactions: 125108 files (54 per second)
125224 read (54 per second)
124584 appended (53 per second)
125608 deleted (54 per second)
Deletion alone: 716 files (358 per second)
Mixed with transactions: 124892 files (54 per second)

Data:
41835.69 megabytes read (18.06 megabytes per second)
42011.05 megabytes written (18.13 megabytes per second)

And the Linux score:

Time:
38 seconds total
38 seconds of transactions (6578 per second)

Files:
125608 created (3305 per second)
Creation alone: 500 files (500 per second)
Mixed with transactions: 125108 files (3292 per second)
125224 read (3295 per second)
124584 appended (3278 per second)
125608 deleted (3305 per second)
Deletion alone: 716 files (716 per second)
Mixed with transactions: 124892 files (3286 per second)

Data:
41835.69 megabytes read (1100.94 megabytes per second)
42011.05 megabytes written (1105.55 megabytes per second)

You can compare those two yourself. It's a huge difference, but not unexpected, considering VMS FS overhead.

Finally, CppPerformanceBenchmarks, compiled with "clang -O3 -march=native -std=c++14" (I used the same Clang flags on Linux, with Clang 15 vs. Clang 10 on VMS). I had to patch ctype.cpp because some of the ctype.h functions/macros returned different results on VMS, which returns true for more values for iscntrl(), isgraph(), isprint(), and ispunct(). Setting LC_ALL to "UTF8-50" didn't make any difference in performance, including in calls to toupper() and tolower().

This time I have Linux numbers first, and the ratio is VMS / Linux time:

atol:

Total time for atol: 4.57 sec, VMS = 30.88 s (6.76x)
Total time for atol hex: 4.47 sec, VMS = 30.07 s (6.73x)
Total time for atof: 20.76 sec, VMS = 71.53 s (3.45x)
Total time for atof E: 20.14 sec, VMS = 66.36 s (3.29x)

ctype:

(first line is isdigit(), etc., tests, second line is tolower()/toupper())

Total time for uint8_t ctype: 7.36 sec, VMS = 56.87 s (7.73x)
Total time for uint8_t ctype: 2.65 sec, VMS = 10.25 s (3.87x)

stepanov_abstraction:

Total time for Abstraction Accumulate: 18.60 sec, VMS = 31.05 s (1.67x)
Total time for Abstraction Insertion Sort: 2.21 sec, VMS = 2.21 s (1.0x)
Total time for Abstraction Quicksort: 3.30 sec, VMS = 3.37 s (1.02x)
Total time for Abstraction Heap Sort: 1.93 sec, VMS = 2.01 s (1.04x)

stepanov_vector:

Total time for Vector accumulate: 37.21 sec, VMS = 481.31 s (12.93x)
Total time for Vector Insertion Sort: 4.36 sec, VMS = 5.61 s (1.29x)
Total time for Vector Quicksort: 13.10 sec, VMS = 28.37 s (2.17x)
Total time for Vector Heap Sort: 8.78 sec, VMS = 23.16 s (2.64x)

random_numbers:

Total time for random seeding: 336.73 sec, VMS = 312.53 s (0.93x)
Total time for random values: 11.28 sec, VMS = 171.74 s (15.23x)
Total time for std random templates: 658.57 sec, VMS = 689.86 s (1.05x)

functionobjects:

Total absolute time for Function Objects: 11.47 sec, VMS = 14.02 s (1.22x)

mathlib:

Total time for double mathlib: 164.86 sec, VMS = 1580.39 s (9.59x)
Total time for float mathlib: 92.16 sec, VMS = 1320.29 s (14.33x)

There's a lot of room for improvement in a few of the C++ microbenchmarks, like mathlib, vector accumulate, ctype functions, and atol functions. More importantly, the code compiles and runs as C++14 in OpenVMS x86, which wasn't possible on Alpha or Itanium.

Best regards,
Jake Hamby

On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>
> First, OpenSSH, which suffers greatly from not being built for VMS
> with x86 assembler optimizations.

Probably important.

> Curiously, the 4096 bit RSA test
> was nearly 60% faster when run on the Linux host rather than inside
> my Ubuntu Server VM. Since it's the same version of OpenSSH, and the
> other speed tests gave identical results between bare metal and Linux
> VM, I don't know what to attribute that to.
>
> Here are the VMS and Linux speeds, followed by the ratio of Linux to
> VMS (higher scores are better). All results are the average of 3
> runs. >
> rsa 4096 bits sign/s: VMS = 11.8, Linux = 233.3 (19.77x)
> rsa 4096 bits verify/s: VMS = 852.4, Linux = 15021.5 (17.62x)
>
> (Following numbers are in 1000s of bytes per second processed)
>
> sha256, 16 bytes: VMS = 768.04k, Linux = 77014.12k (100.27x)
> sha256: 64 bytes: VMS = 2965.24k, Linux = 200264.14k (67.54x)
> sha256: 256 bytes: VMS = 10837.12k, Linux = 421229.97k (38.87x)
> sha256: 1024 bytes: VMS = 32547.53k, Linux = 577376.77k (17.74x)
> sha256: 8192 bytes: VMS = 78364.77k, Linux = 644813.20k (8.23x)
> sha256: 16384 bytes: VMS = 87204.63k, Linux = 649131.38k (7.44x)
>
> sha512 , 16 bytes: VMS = 770.86k, Linux = 57818.49k (75.01x)
> sha512 : 64 bytes: VMS = 3081.86k, Linux = 231261.67k (75.04x)
> sha512 : 256 bytes: VMS = 11691.87k, Linux = 469829.08k (40.18x)
> sha512 : 1024 bytes: VMS = 40253.92k, Linux = 770282.03k (19.14x)
> sha512 : 8192 bytes: VMS = 140511.75k, Linux = 955133.22k (6.80x)
> sha512 : 16384 bytes: VMS = 171268.94k, Linux = 971181.22k (5.67x)
>
> AES-128-GCM, 16 bytes: VMS = 52389.06k, Linux = 731482.29k (13.96x)
> AES-128-GCM: 64 bytes: VMS = 64247.33k, Linux = 1867970.54k (29.07x)
> AES-128-GCM: 256 bytes: VMS = 70553.48k, Linux = 3713979.67k (52.64x)
> AES-128-GCM: 1024 bytes: VMS = 72296.92k, Linux = 6027351.62k (83.37x)
> AES-128-GCM: 8192 bytes: VMS = 72317.90k, Linux = 7630128.89k (105.51x)
> AES-128-GCM: 16384 bytes: VMS = 72337.10k, Linux = 7799369.48k (107.82x)
>
> AES-256-GCM, 16 bytes: VMS = 47903.51k, Linux = 634127.50k (13.24x)
> AES-256-GCM: 64 bytes: VMS = 57722.18k, Linux = 1750850.44k (30.33x)
> AES-256-GCM: 256 bytes: VMS = 62676.83k, Linux = 3131857.16k (49.97x)
> AES-256-GCM: 1024 bytes: VMS = 63982.17k, Linux = 4711443.18k (73.64x)
> AES-256-GCM: 8192 bytes: VMS = 64375.58k, Linux = 5595369.92k (86.92x)
> AES-256-GCM: 16384 bytes: VMS = 64263.75k, Linux = 5673393.94k (88.28x)
>
> ChaCha20, 16 bytes: VMS = 76456.19k, Linux = 534685.07k (6.99x)
> ChaCha20: 64 bytes: VMS = 100830.84k, Linux = 970432.25k (9.62x)
> ChaCha20: 256 bytes: VMS = 109619.82k, Linux = 2026910.42k (18.49x)
> ChaCha20: 1024 bytes: VMS = 112586.76k, Linux = 4098876.65k (36.41x)
> ChaCha20: 8192 bytes: VMS = 113955.06k, Linux = 4287163.43k (37.62x)
> ChaCha20: 16384 bytes: VMS = 114424.67k, Linux = 4303112.74k (37.61x)
>
> ChaCha20-Poly1305, 16 bytes: VMS = 56328.32k, Linux = 401319.24k (7.12x)
> ChaCha20-Poly1305: 64 bytes: VMS = 83036.66k, Linux = 768498.64k (9.25x)
> ChaCha20-Poly1305: 256 bytes: VMS = 90210.62k, Linux = 1564155.33k (17.34x)
> ChaCha20-Poly1305: 1024 bytes: VMS = 93680.18k, Linux = 2820100.89k (30.10x)
> ChaCha20-Poly1305: 8192 bytes: VMS = 94924.99k, Linux = 2998130.64k (31.58x)
> ChaCha20-Poly1305: 16384 bytes: VMS = 95001.36k, Linux = 3010321.70k (31.69x)

If VMS use generic C code compiled to normal instructions while
the Linux version use assembly and utilize various specialized
x86-64 instructions (like AES-NI for AES encryption) then not
so surprising that VMS is slow.

> Finally, CppPerformanceBenchmarks, compiled with "clang -O3
> -march=native -std=c++14" (I used the same Clang flags on Linux, with
> Clang 15 vs. Clang 10 on VMS). I had to patch ctype.cpp because some
> of the ctype.h functions/macros returned different results on VMS,
> which returns true for more values for iscntrl(), isgraph(),
> isprint(), and ispunct(). Setting LC_ALL to "UTF8-50" didn't make any
> difference in performance, including in calls to toupper() and
> tolower().
>
> This time I have Linux numbers first, and the ratio is VMS / Linux
> time: >
> atol:
>
> Total time for atol: 4.57 sec, VMS = 30.88 s (6.76x)
> Total time for atol hex: 4.47 sec, VMS = 30.07 s (6.73x)
> Total time for atof: 20.76 sec, VMS = 71.53 s (3.45x)
> Total time for atof E: 20.14 sec, VMS = 66.36 s (3.29x)

This may be a case where the fact that VMS incl. RTLs are
build with non-optimizing compilers (cross-compilers on Itanium)
actually matters.

I suspect that atol & atof speed is significantly impacted by
optimizing vs non-optimizing.

Arne

On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>
>> First, OpenSSH, which suffers greatly from not being built for VMS
>> with x86 assembler optimizations.
>
> Probably important.
>

Even allowing for that, and allowing for un-optimised compilers, those
numbers are horrible.

Jake has performed a good service here and I hope VSI don't ignore him.

He has given VSI some solid data and specific tests to identify these
performance issues and which can be used to benchmark any changes VSI
makes.

Jake, one thing that did occur to me just now: does the hardware/VM
you are testing under have PCID support ? x86-64 VMS relies on this
to avoid massive overheads from the need to emulate executive and
supervisor mode in software.

Simon.

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

On 2023-10-11 15:01, Simon Clubley wrote:
> On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>>
>>> First, OpenSSH, which suffers greatly from not being built for VMS
>>> with x86 assembler optimizations.
>>
>> Probably important.
>>
>
> Even allowing for that, and allowing for un-optimised compilers, those
> numbers are horrible.

The numbers are not encouraging, I agree. But at the same time, I'm not
surprised based on the comment about optimizations here...

> Jake has performed a good service here and I hope VSI don't ignore him.
>
> He has given VSI some solid data and specific tests to identify these
> performance issues and which can be used to benchmark any changes VSI
> makes.
>
> Jake, one thing that did occur to me just now: does the hardware/VM
> you are testing under have PCID support ? x86-64 VMS relies on this
> to avoid massive overheads from the need to emulate executive and
> supervisor mode in software.

I doubt that plays any larger part here. This would not be some page
thrashing, or excessive system calls and context switches.

OpenSSH performance is all about really big math. Having that in
hand-tuned assembler makes an enormous difference. There is a reason why
a lot of stuff in this specific area is hand tuned assembler.
I dealt peripherally with this on NetBSD/vax in the past. It's assembler
there too, because performance otherwise was just horrible.

Johnny

On Wednesday, October 11, 2023 at 9:54:24 AM UTC-7, Johnny Billquist wrote:
> On 2023-10-11 15:01, Simon Clubley wrote:
> >
> > Jake, one thing that did occur to me just now: does the hardware/VM
> > you are testing under have PCID support ? x86-64 VMS relies on this
> > to avoid massive overheads from the need to emulate executive and
> > supervisor mode in software.
> I doubt that plays any larger part here. This would not be some page
> thrashing, or excessive system calls and context switches.

I do have PCID, and I agree that it probably doesn't matter here. Here's the output of SYSINFO, which only shows missing optional features, and PCID isn't listed.

PROCESSORS: Max Supported: 64, SMP? Yes, Hyperthreads? No
Type: Intel(R) Xeon(R) W-1290P CPU @ 3.70GHz

PERFORMING HARDWARE COMPATIBILITY TEST.

Checking Required Processor Features:
PASSED

Checking Optional Features:
- No XSAVEOPT instruction
- No TSX-HLE instruction
- No TSX-RTM instruction
- No UMIP instruction
FAILED

BTW, this was the output that encouraged me to enable "x2apic" in my VirtualBox config, which removed a line about missing that feature.

> OpenSSH performance is all about really big math. Having that in
> hand-tuned assembler makes an enormous difference. There is a reason why
> a lot of stuff in this specific area is hand tuned assembler.
> I dealt peripherally with this on NetBSD/vax in the past. It's assembler
> there too, because performance otherwise was just horrible.

Yep. "openssl speed" returns info about how it was compiled. The Ubuntu package was built using GCC with "-O2" and LTO, which likely makes a big difference, enabling optimizations such as cross-file function inlining.

built on: Wed May 24 17:12:55 2023 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-
Z1YLmC/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -
Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUIL
DING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
CPUINFO: OPENSSL_ia32cap=0xdefa2223478bffff:0x842529

Here's what OpenVMS SSL3 V3.0-11 prints:

built on: Tue Sep 26 15:49:20 2023 UTC
options: bn(64,64)
compiler: CC/DECC /DEFINE=(OPENSSL_PIC,OPENSSL_NO_ASM,OPENSSL_BUILDING_OPENSSL,
_SOCKADDR_LEN,NDEBUG,OPENSSLDIR="""SSL3$ROOT:[000000]""",ENGINESDIR="""SSL3$ENGI
NES:""",MODULESDIR="""SSL3$MODULES:"""'extradefines')/INCLUDE=()/DEFINE=(OPENSSL
_PIC,OPENSSL_NO_ASM,OPENSSL_BUILDING_OPENSSL,_SOCKADDR_LEN,NDEBUG,OPENSSLDIR="""
SSL3$ROOT:[000000]""",ENGINESDIR="""SSL3$ENGINES:""",MODULESDIR="""SSL3$MODULES:
"""'extradefines')
CPUINFO: N/A

So it looks like enabling x86 assembler in OpenSSL for VMS will also require writing code to get the CPU capabilities (OPENSSL_ia32cap) in order to select the fastest accelerated version of each algorithm supported by the CPU..

I haven't tested this myself yet, but I wonder if Clang can be used to compile C source files in order to generate better code than using the VSI C frontend and GEM-to-LLVM translator. On Itanium, CXX generated better code than CC, but I didn't know of a way to use it to compile C code. That might be a quicker path to getting inline asm working, which I suspect is required to enable asm in OpenSSL (it has standalone .s files as well, which the port of "llvm-mc" should be able to handle).

LTO support is a lot of work, because you have to modify the entire toolchain to deal with bitcode in object files and the final LTO compile/link stage, and even then I've often run into cases where enabling LTO breaks the resulting program behavior in strange ways (QEMU is one example that comes to mind). Enabling LTO won't make a 6x difference, but enabling asm optimizations and possibly switching to Clang should close the gap.

VSI C has a quasi-LTO feature called /PLUS_LIST_OPTIMIZE that might be worth testing, although it requires modifications to the build scripts to put all the source files into a single compile command.

Regards,
Jake

On 2023-10-11, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-10-11 15:01, Simon Clubley wrote:
>>
>> Jake, one thing that did occur to me just now: does the hardware/VM
>> you are testing under have PCID support ? x86-64 VMS relies on this
>> to avoid massive overheads from the need to emulate executive and
>> supervisor mode in software.
>
> I doubt that plays any larger part here. This would not be some page
> thrashing, or excessive system calls and context switches.
>
> OpenSSH performance is all about really big math. Having that in
> hand-tuned assembler makes an enormous difference. There is a reason why
> a lot of stuff in this specific area is hand tuned assembler.
> I dealt peripherally with this on NetBSD/vax in the past. It's assembler
> there too, because performance otherwise was just horrible.
>

For the compute-only stuff I agree with you, but a number of those
tests are I/O-based tests and the results are far worse than even I
was expecting. If the I/O functionality is implemented via RMS, then
that's a trip through executive mode for each I/O request.

To be fair to VMS, we need to be sure that Jake is running VMS in an
environment where PCID is enabled.

Simon.

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

On 2023-10-11, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
> On Wednesday, October 11, 2023 at 9:54:24?AM UTC-7, Johnny Billquist wrote:
>> On 2023-10-11 15:01, Simon Clubley wrote:
>> >
>> > Jake, one thing that did occur to me just now: does the hardware/VM
>> > you are testing under have PCID support ? x86-64 VMS relies on this
>> > to avoid massive overheads from the need to emulate executive and
>> > supervisor mode in software.
>> I doubt that plays any larger part here. This would not be some page
>> thrashing, or excessive system calls and context switches.
>
> I do have PCID, and I agree that it probably doesn't matter here. Here's the output of SYSINFO, which only shows missing optional features, and PCID isn't listed.
>

Thanks for checking that Jake. As mentioned in my other posting, I was
referring to the tests that are I/O based, not compute based.

Have you had any feedback from VSI about your results ?

Simon.

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

On Wednesday, October 11, 2023 at 10:28:48 AM UTC-7, Simon Clubley wrote:
> On 2023-10-11, Jake Hamby (Solid State Jake) <jake....@gmail.com> wrote:
> > On Wednesday, October 11, 2023 at 9:54:24?AM UTC-7, Johnny Billquist wrote:
> >> On 2023-10-11 15:01, Simon Clubley wrote:
> >> >
> >> > Jake, one thing that did occur to me just now: does the hardware/VM
> >> > you are testing under have PCID support ? x86-64 VMS relies on this
> >> > to avoid massive overheads from the need to emulate executive and
> >> > supervisor mode in software.
> >> I doubt that plays any larger part here. This would not be some page
> >> thrashing, or excessive system calls and context switches.
> >
> > I do have PCID, and I agree that it probably doesn't matter here. Here's the output of SYSINFO, which only shows missing optional features, and PCID isn't listed.
> >
> Thanks for checking that Jake. As mentioned in my other posting, I was
> referring to the tests that are I/O based, not compute based.
>
> Have you had any feedback from VSI about your results ?
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I've been watching the discussions and will have them looked at soon.
We're kinda busy with other things.

The current C compiler is a little old and we found that we aren't enabling
all of the LLVM optimization passes. And we still have to generate TBAA
metadata.

If you use clang as a foreign-command, it will see the ".c" suffix and compile
as a C program. The CXX command always assumes the source is C++
regardless of the suffix (just like Alpha/Itanium).

On 10/11/23 2:50 PM, John Reagan wrote:

> If you use clang as a foreign-command, it will see the ".c" suffix and compile
> as a C program. The CXX command always assumes the source is C++
> regardless of the suffix (just like Alpha/Itanium).

I'm not the expert here (John is), but I think the source *can* be valid
(albeit "dumb") C++ even if it's nominally C. For example, the Perl
sources are tested to build with C++ compilers because some people write
extensions in C++, but almost no one builds Perl core in C.

If you've got a large C project that has never been thrown at a C++
compiler, then you would have some work to do to make it compile. But,
it is entirely possible to have valid C that is also valid C++.

On 10/11/23 6:11 PM, Craig A. Berry wrote:
> On 10/11/23 2:50 PM, John Reagan wrote:
>
>> If you use clang as a foreign-command, it will see the ".c" suffix and
>> compile
>> as a C program.  The CXX command always assumes the source is C++
>> regardless of the suffix (just like Alpha/Itanium).
>
> I'm not the expert here (John is), but I think the source *can* be valid
> (albeit "dumb") C++ even if it's nominally C.  For example, the Perl
> sources are tested to build with C++ compilers because some people write
> extensions in C++, but almost no one builds Perl core in C.

Darn it, meant to say C++, not C there.

> If you've got a large C project that has never been thrown at a C++
> compiler, then you would have some work to do to make it compile. But,
> it is entirely possible to have valid C that is also valid C++.
>
>

On Wednesday, October 11, 2023 at 4:11:28 PM UTC-7, Craig A. Berry wrote:
>
> I'm not the expert here (John is), but I think the source *can* be valid
> (albeit "dumb") C++ even if it's nominally C. For example, the Perl
> sources are tested to build with C++ compilers because some people write
> extensions in C++, but almost no one builds Perl core in C.
>
> If you've got a large C project that has never been thrown at a C++
> compiler, then you would have some work to do to make it compile. But,
> it is entirely possible to have valid C that is also valid C++.

You're right. That's what I was planning to do if necessary. That's what I was doing on Itanium to get better performance using Intel's C++ frontend.

I'm going to try building Perl from source using the C++ compiler on x86 to see what happens. I saw some strange build failures that I couldn't figure out the last time I tried on Itanium, using CC or CXX, and using MMS or MMK.

Regards,
Jake

On Wednesday, October 11, 2023 at 6:18:43 PM UTC-7, Jake Hamby (Solid State Jake) wrote:
>
> I'm going to try building Perl from source using the C++ compiler on x86 to see what happens. I saw some strange build failures that I couldn't figure out the last time I tried on Itanium, using CC or CXX, and using MMS or MMK.

Oh no, look what happened when I tried to build Perl 5.38.0 using DECC just now (no unusual configure options):

CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=sv.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
sv.c
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=800000000000
0000, PC=0000000000AA4F9A, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$COMPILER [.src]g2l_constant.cxx scalarConstant<llvm::ConstantFP, long double>
#101 0000000000AA4F9A 0000000000AA4F9A
DECC$COMPILER [.src]g2l_constant.cxx constantWithBuffer
#155 0000000000AA44AE 0000000000AA44AE
DECC$COMPILER [.src]g2l_constant.cxx createLlvmConstant
#123 0000000000AA439C 0000000000AA439C
DECC$COMPILER [.src]g2l_constant.cxx newG2lLiteral
#269 0000000000AA4CE0 0000000000AA4CE0
DECC$COMPILER [.src]g2l_operator.cxx getLlvmOperand
#1742 0000000000A60A56 0000000000A60A56
DECC$COMPILER [.src]g2l_operator.cxx processTuple
#1073 0000000000A5FB45 0000000000A5FB45
DECC$COMPILER [.src]g2l_routine.cxx this
#1374 0000000000A57F6C 0000000000A57F6C
DECC$COMPILER [.src]g2l_routine.cxx this
#729 0000000000A56D2A 0000000000A56D2A
DECC$COMPILER [.src]g2l_module.cxx convertDeclarations
#1576 0000000000A47522 0000000000A47522
DECC$COMPILER [.src]g2l_module.cxx convertDeclarations
#1569 0000000000A474AF 0000000000A474AF
DECC$COMPILER [.src]g2l_module.cxx convertModule
#1165 0000000000A44603 0000000000A44603
DECC$COMPILER [.src]g2l_module.cxx G2L_COMPILE_MODULE
#619 0000000000A43181 0000000000A43181
DECC$COMPILER GEM_CO.BLI;1 GEM_CO_COMPILE_MODULE
#3223 0000000000000A54 00000000006D8844
DECC$COMPILER COMPILE.C;1 gemc_be_master
#103704 00000000004238BE 00000000004238BE
DECC$COMPILER COMPILE.C;1 gem_xx_compile
#102915 0000000000422597 0000000000422597
DECC$COMPILER GEM_CP_VMS.BLI;1 GEM_CP_MAIN
#2447 000000000000384E 00000000006CC23E
DECC$COMPILER 0 0000000000AD36A4 0000000000AD36A4
DECC$COMPILER 0 00000000021887AD 00000000021887AD
PTHREAD$RTL 0 000000008004122C FFFF83000950722C
PTHREAD$RTL 0 0000000080002316 FFFF8300094C8316
0 FFFF8300081FC0A6 FFFF8300081FC0A6
DCL 0 000000008006778B 000000007ADEB78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump
%MMS-F-ABORT, For target sv.obj, CLI returned abort status: %X1000000C.
$ cc/version
VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 V9.2-1

On 10/11/2023 9:01 AM, Simon Clubley wrote:
> Jake has performed a good service here and I hope VSI don't ignore him.

Two VSI people has already replied to his threads, so I think we
can conclude that they will not ignore him.

:-)

Arne

On 10/11/23 8:44 PM, Jake Hamby (Solid State Jake) wrote:
> On Wednesday, October 11, 2023 at 6:18:43 PM UTC-7, Jake Hamby (Solid State Jake) wrote:
>>
>> I'm going to try building Perl from source using the C++ compiler on x86 to see what happens. I saw some strange build failures that I couldn't figure out the last time I tried on Itanium, using CC or CXX, and using MMS or MMK.
>
> Oh no, look what happened when I tried to build Perl 5.38.0 using DECC just now (no unusual configure options):
>
> CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=sv.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
> sv.c
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=800000000000
> 0000, PC=0000000000AA4F9A, PS=0000001B

As documented in the release notes, initializing long doubles is not
supported yet. You'll want to configure with something like this:

@configure -"Dusedevel" -"DDEBUGGING" -"Duser_c_flags=/L_DOUBLE=64"
-"Dusevmsdebug" -"des"

On 10/11/23 8:18 PM, Jake Hamby (Solid State Jake) wrote:
> On Wednesday, October 11, 2023 at 4:11:28 PM UTC-7, Craig A. Berry wrote:
>>
>> I'm not the expert here (John is), but I think the source *can* be valid
>> (albeit "dumb") C++ even if it's nominally C. For example, the Perl
>> sources are tested to build with C++ compilers because some people write
>> extensions in C++, but almost no one builds Perl core in C.
>>
>> If you've got a large C project that has never been thrown at a C++
>> compiler, then you would have some work to do to make it compile. But,
>> it is entirely possible to have valid C that is also valid C++.
>
> You're right. That's what I was planning to do if necessary. That's
> what I was doing on Itanium to get better performance using Intel's
> C++ frontend.
>
> I'm going to try building Perl from source using the C++ compiler on
> x86 to see what happens. I saw some strange build failures that I
> couldn't figure out the last time I tried on Itanium, using CC or
> CXX, and using MMS or MMK.

The last time I got a good compile with the C++ 03 compiler on Itanium,
I configured like so:

@configure -"DDEBUGGING" -"Dusevmsdebug" -"Dusecxx"
-"Duser_c_flags=/WARN=INFORMATIONAL=NOCTOBUTCONREFM" -"des"

It's completely unknown, at least by me, what will happen when feeding
that to the CXX command on OpenVMS x86. I'd expect some trouble related
to 64-bit pointers.

On 10/11/2023 9:01 AM, Simon Clubley wrote:
> On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>>
>>> First, OpenSSH, which suffers greatly from not being built for VMS
>>> with x86 assembler optimizations.
>>
>> Probably important.
>>
>
> Even allowing for that, and allowing for un-optimised compilers, those
> numbers are horrible.

The difference between un-optimized and optimized can be
pretty big - like a factor 3-5.

The difference between generic C code implementation
of algorithm and assembler using special instructions
could be even bigger - the AES-NI instructions for AES
are supposedly a factor 4-8 faster.

So I don't see anything horrible in the numbers.

Obviously there are issues that VSI need to look at. And
I would expect them to look at them in due time.

Right now VSI's business priority has to be to get
existing VMS Alpha and Itanium customers to migrate
to VMS x86-64.

There are several must haves in that area: getting
VMS Basic out, fixing a bunch of compiler errors etc..

I don't think the speed of the OpenSSL functions is going
to stop anyone from migrating.

The current VMS x86-64 code on current HW is probably
as fast as VMS Itanium on 10 year old Itanium systems
and faster than VMS Alpha on 20 year old Alpha systems.

So I think it will do for now. VMS customers can proceed
with their migration as it will run.

The fact that they can expect some very significant performance
improvements in the next 6-12-24 months is just icing on the cake.

Classic: Make It Work Make It Right Make It Fast.

And look at the positive side: lots of testing is happening and
VMS generally seems as solid as always. It is a lot better to hear
stories about some things being slower than their potential due to
lack of optimization than to hear about OS crashes!!

Yes - feel free to consider me a "the cup is half full" person
instead of a "the cup is half empty" person.

Arne

On 10/11/2023 3:50 PM, John Reagan wrote:
> The current C compiler is a little old and we found that we aren't enabling
> all of the LLVM optimization passes. And we still have to generate TBAA
> metadata.
>
> If you use clang as a foreign-command, it will see the ".c" suffix and compile
> as a C program. The CXX command always assumes the source is C++
> regardless of the suffix (just like Alpha/Itanium).

Did you see the numbers for different compilers that
I posted 1-Oct-2023?

It looks like right now the fastest compilers are C++
and Java.

Arne

On 2023-10-11, Craig A. Berry <craigberry@nospam.mac.com> wrote:
> On 10/11/23 2:50 PM, John Reagan wrote:
>
>> If you use clang as a foreign-command, it will see the ".c" suffix and compile
>> as a C program. The CXX command always assumes the source is C++
>> regardless of the suffix (just like Alpha/Itanium).
>
> I'm not the expert here (John is), but I think the source *can* be valid
> (albeit "dumb") C++ even if it's nominally C. For example, the Perl
> sources are tested to build with C++ compilers because some people write
> extensions in C++, but almost no one builds Perl core in C.
>

There is one area I immediately know of in which that has not been true
until recently (C++20) and that is C's designated initialisers. Until
recently, they were not supported in C++.

You need to compile such a program in C mode, not C++ mode. No prizes for
guessing how I know all this. :-)

> If you've got a large C project that has never been thrown at a C++
> compiler, then you would have some work to do to make it compile. But,
> it is entirely possible to have valid C that is also valid C++.
>

An enforced project-wide -Wall and -Werror are both good tools here.

Simon.

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

On 2023-10-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/11/2023 9:01 AM, Simon Clubley wrote:
>> On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>>>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>>>
>>>> First, OpenSSH, which suffers greatly from not being built for VMS
>>>> with x86 assembler optimizations.
>>>
>>> Probably important.
>>>
>>
>> Even allowing for that, and allowing for un-optimised compilers, those
>> numbers are horrible.
>
> The difference between un-optimized and optimized can be
> pretty big - like a factor 3-5.
>
> The difference between generic C code implementation
> of algorithm and assembler using special instructions
> could be even bigger - the AES-NI instructions for AES
> are supposedly a factor 4-8 faster.
>
> So I don't see anything horrible in the numbers.
>

I think it's reasonable for the CPU tests to see what happens with
finished compilers.

However, look again at the filesystem numbers.

Even with unoptimised compilers, they should not be _that_ bad.

Simon.

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

On 2023-10-12 14:27, Simon Clubley wrote:
> On 2023-10-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/11/2023 9:01 AM, Simon Clubley wrote:
>>> On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>>>>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>>>>
>>>>> First, OpenSSH, which suffers greatly from not being built for VMS
>>>>> with x86 assembler optimizations.
>>>>
>>>> Probably important.
>>>>
>>>
>>> Even allowing for that, and allowing for un-optimised compilers, those
>>> numbers are horrible.
>>
>> The difference between un-optimized and optimized can be
>> pretty big - like a factor 3-5.
>>
>> The difference between generic C code implementation
>> of algorithm and assembler using special instructions
>> could be even bigger - the AES-NI instructions for AES
>> are supposedly a factor 4-8 faster.
>>
>> So I don't see anything horrible in the numbers.
>>
>
> I think it's reasonable for the CPU tests to see what happens with
> finished compilers.
>
> However, look again at the filesystem numbers.
>
> Even with unoptimised compilers, they should not be _that_ bad.

What kind of file system related operations do OpenSSH do???

Johnny

On 2023-10-12, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-10-12 14:27, Simon Clubley wrote:
>> On 2023-10-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 10/11/2023 9:01 AM, Simon Clubley wrote:
>>>> On 2023-10-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 10/10/2023 3:13 PM, Jake Hamby (Solid State Jake) wrote:
>>>>>> As promised, here's another post with Linux vs. VMS performance on OpenSSH, C++ microbenchmarks, PostMark, PerlBench, and PHPBench.
>>>>>>
>>>>>> First, OpenSSH, which suffers greatly from not being built for VMS
>>>>>> with x86 assembler optimizations.
>>>>>
>>>>> Probably important.
>>>>>
>>>>
>>>> Even allowing for that, and allowing for un-optimised compilers, those
>>>> numbers are horrible.
>>>
>>> The difference between un-optimized and optimized can be
>>> pretty big - like a factor 3-5.
>>>
>>> The difference between generic C code implementation
>>> of algorithm and assembler using special instructions
>>> could be even bigger - the AES-NI instructions for AES
>>> are supposedly a factor 4-8 faster.
>>>
>>> So I don't see anything horrible in the numbers.
>>>
>>
>> I think it's reasonable for the CPU tests to see what happens with
>> finished compilers.
>>
>> However, look again at the filesystem numbers.
>>
>> Even with unoptimised compilers, they should not be _that_ bad.
>
> What kind of file system related operations do OpenSSH do???
>

If you actually read the posting Johnny, you will see there are many
tests, not just OpenSSL ones. These include filesystem tests with
hideous VMS performance results when compared to Linux.

Simon.

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

On Thursday, October 12, 2023 at 7:15:36 AM UTC-7, Johnny Billquist wrote:
> On 2023-10-12 14:27, Simon Clubley wrote:
> >
> > I think it's reasonable for the CPU tests to see what happens with
> > finished compilers.
> >
> > However, look again at the filesystem numbers.
> >
> > Even with unoptimised compilers, they should not be _that_ bad.
> What kind of file system related operations do OpenSSH do???

I snuck in one filesystem benchmark, PostMark, and left the reader to do the math. Here they are together:

Time:
Linux: 38, VMS: 2317 sec total (61.0x)
Linux: 38, VMS: 2311 (60.8x) sec of transactions (Linux: 6578, VMS: 108 per sec) (36.5x)

Files:
125608 created (Linux: 3305, VMS: 54 per second) (61.2x)
Creation alone: 500 files (Linux: 500, VMS: 125 per second) (4.0x)
Mixed with transactions: 125108 files (Linux: 3292, VMS: 54 per second) (61..0x)
125224 read (Linux: 3295, VMS: 54 per second) (61.0x)
124584 appended (Linux: 3278, VMS: 53 per second) (61.8x)
125608 deleted (Linux: 3305, VMS: 54 per second) (61.2x)
Deletion alone: 716 files (Linux: 716, VMS: 358 per second) (2.0x)
Mixed with transactions: 124892 files (Linux: 3286, VMS: 54 per second) (60..9x)

Data:
41835.69 megabytes read (Linux: 1100.94, VMS: 18.06 megabytes per second) (61.0x)
42011.05 megabytes written (Linux: 1105.55, VMS: 18.13 megabytes per second) (61.0x)

I have a part 3 post that I'm working on to compare IPC latency and throughput, using ZeroMQ's included benchmarks and an open-source IPC benchmark that I ported to VMS to test Itanium last year:

https://github.com/jhamby/vms-ipc_benchmark

I think it's just a fact of life that Linux is going to be ~61x the speed of VMS for file creation and deletion, compared to a journaled filesystem like ext4. I have host-side disk caching enabled for both VMs, using the LsiLogic controller.

The 61x performance gap in PostMark for reads and writes is more worrisome and I'll have to see if there's an easy way to modify the code to close the gap. Based on both my own experiences and reading the stories of others posted here, I'm convinced that tuning for performance is VMS's Achilles' heel, because there are so many system parameters and quota limits and buffer size adjustments that just aren't needed on Linux/UNIX, Mac, or Windows.

Someone should work on an auto-setup script for novices to walk them through the arcane setup aspects that I was dreading have to remember how to do when setting up my VM, like increasing a bunch of resource quotas for SYSTEM, copying them to a new user account, adding some MODPARAMS.DAT values for SAMBA, running AUTOGEN, running UETP to exercise the system, etc..

Out of the box, the only suboptimal buffer sizing I can think of in Linux/UNIX/Mac, and it's for backward compatibility, is that "dd" defaults to 512-byte reads/writes, and usually benefits from setting a block size like 64K or 1MB, and that's something people generally learn when they find out about the "dd" command. Someone mentioned that here recently.

I have a part 3 post that I'm working on to compare IPC latency and throughput, using ZeroMQ's included benchmarks and an open-source IPC benchmark that I ported to VMS to test Itanium last year:

https://github.com/jhamby/vms-ipc_benchmark

I couldn't get the System V shared mem test to work on VMS even though the C RTL is supposed to implement the APIs. There are a few other filesystem benchmarks I'd eventually like to try, but they have ./configure scripts and Makefiles I'd have to port. What I can do for part 3 is compare the SQLite benchmark on Linux to the VMS port of SQLite that was mentioned here recently.

Regards,
Jake Hamby

On 2023-10-12, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
>
> I think it's just a fact of life that Linux is going to be ~61x the speed of VMS for file creation and deletion, compared to a journaled filesystem like ext4. I have host-side disk caching enabled for both VMs, using the LsiLogic controller.
>

That would seem to mostly address any concerns about the different levels
of filesystem caching in VMS and Linux.

> The 61x performance gap in PostMark for reads and writes is more worrisome and I'll have to see if there's an easy way to modify the code to close the gap. Based on both my own experiences and reading the stories of others posted here, I'm convinced that tuning for performance is VMS's Achilles' heel, because there are so many system parameters and quota limits and buffer size adjustments that just aren't needed on Linux/UNIX, Mac, or Windows.
>

Yes it is. Are your tests going via RMS ?

If so, do you have any tests that can do QIOs directly so you bypass RMS
and go directly to the VMS kernel ?

If you are going via RMS, we don't know from these numbers how much time
is being lost in RMS and how much is being lost in VMS kernel mode code.

Simon.

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

On Wednesday, October 11, 2023 at 6:55:02 PM UTC-7, Craig A. Berry wrote:
> As documented in the release notes, initializing long doubles is not
> supported yet. You'll want to configure with something like this:
>
> @configure -"Dusedevel" -"DDEBUGGING" -"Duser_c_flags=/L_DOUBLE=64"
> -"Dusevmsdebug" -"des"

Adding "/L_DOUBLE=64" was exactly the workaround I needed, thanks!

My build appears to be progressing now. I didn't use the debugging flags from your example. I tried building without /NAMES=SHORTENED because the release notes say the default is to not truncate symbols, but the build failed immediately with a warning about having to truncate a symbol to 31 chars.

Now I'm running into the same build failures due to missing targets that I was seeing with Itanium. I think I have to deassign all of the DECC$ logicals that the JDK startup script sets:

$ define decc$fd_locking true
$ define decc$efs_case_preserve enable ! Enable ODS-5 names
$ define decc$readdir_dropdotnotype enable
$ define decc$efs_charset enable
$ define decc$argv_parse_style enable

If decc$readdir_dropdotnotype is enabled, the build fails fairly early because it adds and extra "." into a directory name. If I deassign that logical only, I get a build failure about not finding a rule to build DynaLoader. This is immediately after it builds perl.exe and is starting to build the shared Perl modules.

I started from a newly-extracted Perl 5.38.0 source tree and deassigned all my DECC$* logicals, and now I'm crossing my fingers that this will get me past the DynaLoader build failure. I doubt that "set proc/parse=extended" is incompatible, right?

Regards,
Jake Hamby

On Thursday, October 12, 2023 at 11:59:24 AM UTC-7, Jake Hamby (Solid State Jake) wrote:
>
> If decc$readdir_dropdotnotype is enabled, the build fails fairly early because it adds and extra "." into a directory name. If I deassign that logical only, I get a build failure about not finding a rule to build DynaLoader.. This is immediately after it builds perl.exe and is starting to build the shared Perl modules.
>
> I started from a newly-extracted Perl 5.38.0 source tree and deassigned all my DECC$* logicals, and now I'm crossing my fingers that this will get me past the DynaLoader build failure. I doubt that "set proc/parse=extended" is incompatible, right?

No luck. Here's the build failure I can't get past:

MCR Sys$Disk:[]miniperl.exe "-I[.lib]" make_ext.pl "MAKE=MMS" "DynaLoader"
Generating a MMS-style Descrip.MMS
Writing Descrip.MMS for DynaLoader

MCR DKA0:[local.perl-5^.38^.0]miniperl.exe;2 "-I[--.lib]" DynaLoader_pm.PL DynaLoader.pm
MCR DKA0:[local.perl-5^.38^.0]miniperl.exe;2 "-I[--.lib]" -MExtUtils::Mksymlists -e "Mksymlists('NAME'=>'DynaLoader', 'DLBASE' => 'PL_DynaLoader', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
MCR DKA0:[local.perl-5^.38^.0]miniperl.exe;2 -e "print ""[--.lib.auto.DynaLoader]DynaLoader.olb/Include=DynaLoader\n[--.lib.auto.DynaLoader]DynaLoader.olb/Library\n"";" >>DynaLoader.opt
MCR DKA0:[local.perl-5^.38^.0]miniperl.exe;2 -e "print qq{PerlShr/Share\n}" >>DynaLoader.opt
MCR DKA0:[local.perl-5^.38^.0]miniperl.exe;2 "-I[--.lib]" "-MExtUtils::Command" -e "cp" "--" DynaLoader.opt [-.lib.auto.DynaLoader]DynaLoader.opt
%MMS-F-GWKNOACTS, Actions to update DynaLoader.obj are unknown.
%MMS-F-GWKNOACTS, Actions to update DynaLoader.obj are unknown.

%MMS-F-GWKNOACTS, Actions to update DynaLoader.obj are unknown.
%MMS-F-GWKNOACTS, Actions to update DynaLoader.obj are unknown.

Unsuccessful make(ext/DynaLoader): code=1024 at make_ext.pl line 584.
%MMS-F-NOMSG, Message number 00EE805C
%MMS-F-ABORT, For target DynaLoader.obj, CLI returned abort status: %X00EE805C.
-MMS-F-GWKNOACTS, Actions to update !AS are unknown.

Any ideas what's going on here? I'm going to try renaming the build directory to "perl-5_38" on the off chance that the "." in the build directory name is a problem.

Regards,
Jake Hamby