Hi.

Just saw this: https://wasd.vsm.com.au/info-WASD/2023/0077

> TL;DR obvious profile differences in at least KERNEL mode
> begs some questions about x86-64 VMS.
>
> This item is more about X86 VMS and less about WASD but
> still uses WASD as a part of the measurement process.

Jan-Erik Söderholm schrieb am Donnerstag, 27. April 2023 um 11:24:46 UTC+2:

After now also running a VSI OpenVMS x86-64 E9.2-1 system (using VMware Workstation Player 16) and installing the C compiler, I have tried to 'calibrate' the procedure to obtain the VUPS values for x86-64 using the PRIME_SIEVE.C tool (calculating prime numbers up to 10^10). The CPU_MULTIPLIER value for x86_64 should be set to 8 - you can easily edit this procedure to add (at the right place): $ IF F$GETSYI("ARCH_NAME").EQS."x86_64" THEN $ cpu_multiplier=8

The resulting VUPS values for x86-64 are now more realistic: 5900 VUPS on an i5-9600K CPU @3.7 GHz

On this OpenVMS x86_64 system, PRIME_SIEVE needs 19.34 sec to calculate primes up to 10^10. On an ES45 Model 2B (EV68CB 1250 MHz) system it took 49.04 seconds, that system was measured at 2414 VUPS.

See previous discussion in: https://groups.google.com/g/comp.os.vms/c/ouhZ7C7bgoQ/m/_iEqNzm1AwAJ

PRIME_SIEVE was obtained from http://wwwhomes.uni-bielefeld.de/achim/prime_sieve.html

Volker.

Jan-Erik Söderholm schrieb am Donnerstag, 27. April 2023 um 11:24:46 UTC+2:

> > TL;DR obvious profile differences in at least KERNEL mode
> > begs some questions about x86-64 VMS.

To start looking at the kernel mode usage - if this is already the time to do this - one would start with the PCS$SDA extension (PC sampling).

Volker.

On 2023-04-27, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Hi.
>
> Just saw this: https://wasd.vsm.com.au/info-WASD/2023/0077
>
> > TL;DR obvious profile differences in at least KERNEL mode
> > begs some questions about x86-64 VMS.
> >
> > This item is more about X86 VMS and less about WASD but
> > still uses WASD as a part of the measurement process.
>

I couldn't see in the report whether the underlying x86-64 CPU running
the hypervisor was Intel or AMD.

Running these tests under the hypervisor on both Intel and AMD hardware
would be interesting.

Simon.

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

On 27/4/2023 10:32 pm, Simon Clubley wrote:
> On 2023-04-27, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Hi.
>>
>> Just saw this: https://wasd.vsm.com.au/info-WASD/2023/0077
>>
>>> TL;DR obvious profile differences in at least KERNEL mode
>>> begs some questions about x86-64 VMS.
>>>
>>> This item is more about X86 VMS and less about WASD but
>>> still uses WASD as a part of the measurement process.
>>
>
> I couldn't see in the report whether the underlying x86-64 CPU running
> the hypervisor was Intel or AMD.

Processor Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 3.60 GHz
Installed RAM 16.0 GB

> Running these tests under the hypervisor on both Intel and AMD hardware
> would be interesting.
>
> Simon.
>

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

On 27/4/2023 8:35 pm, Volker Halle wrote:
> Jan-Erik Söderholm schrieb am Donnerstag, 27. April 2023 um 11:24:46 UTC+2:
>
> After now also running a VSI OpenVMS x86-64 E9.2-1 system (using VMware Workstation Player 16) and installing the C compiler, I have tried to 'calibrate' the procedure to obtain the VUPS values for x86-64 using the PRIME_SIEVE.C tool (calculating prime numbers up to 10^10). The CPU_MULTIPLIER value for x86_64 should be set to 8 - you can easily edit this procedure to add (at the right place): $ IF F$GETSYI("ARCH_NAME").EQS."x86_64" THEN $ cpu_multiplier=8

With the VUPS.COM procedure modified to

|$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40
|$ if f$getsyi("arch_name").eqs."x86_64" then $ cpu_multiplier=8

the resultant

|X86VMS$ @vups.com
|innotek GmbH VirtualBox with 2 CPU and 7574MB running VMS V9.2
|Approximate System VUPs Rating : 225.6 ( min: 224.4 max: 226.2 )

down from 272 "VUPs" reported previously, on a commodity DELL SFF with
Windows 10 Pro Version 22H2

Processor Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 3.60 GHz
Installed RAM 16.0 GB

> The resulting VUPS values for x86-64 are now more realistic: 5900 VUPS on an i5-9600K CPU @3.7 GHz
>
> On this OpenVMS x86_64 system, PRIME_SIEVE needs 19.34 sec to calculate primes up to 10^10. On an ES45 Model 2B (EV68CB 1250 MHz) system it took 49.04 seconds, that system was measured at 2414 VUPS.
>
> See previous discussion in: https://groups.google.com/g/comp.os.vms/c/ouhZ7C7bgoQ/m/_iEqNzm1AwAJ
>
> PRIME_SIEVE was obtained from http://wwwhomes.uni-bielefeld.de/achim/prime_sieve.html
>
> Volker.

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

Here is i7-8700K processor (2 CPUs and 8 GB memory allocated on VirtualBox under Windows 11 Pro) - VUPS 420.0

Tim

-----Original Message-----
From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Mark Daniel via Info-vax
Sent: Thursday, April 27, 2023 9:31 AM
To: info-vax@rbnsn.com
Cc: Mark Daniel <mark.daniel@wasd.vsm.com.au>
Subject: Re: [Info-vax] Some VMS/x86 perf test data from WASD maintainer.

On 27/4/2023 8:35 pm, Volker Halle wrote:
> Jan-Erik Söderholm schrieb am Donnerstag, 27. April 2023 um 11:24:46 UTC+2:
>
> After now also running a VSI OpenVMS x86-64 E9.2-1 system (using
> VMware Workstation Player 16) and installing the C compiler, I have
> tried to 'calibrate' the procedure to obtain the VUPS values for
> x86-64 using the PRIME_SIEVE.C tool (calculating prime numbers up to
> 10^10). The CPU_MULTIPLIER value for x86_64 should be set to 8 - you
> can easily edit this procedure to add (at the right place): $ IF
> F$GETSYI("ARCH_NAME").EQS."x86_64" THEN $ cpu_multiplier=8

With the VUPS.COM procedure modified to

|$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40 $ if
|f$getsyi("arch_name").eqs."x86_64" then $ cpu_multiplier=8

the resultant

|X86VMS$ @vups.com
|innotek GmbH VirtualBox with 2 CPU and 7574MB running VMS V9.2
|Approximate System VUPs Rating : 225.6 ( min: 224.4 max: 226.2 )

down from 272 "VUPs" reported previously, on a commodity DELL SFF with Windows 10 Pro Version 22H2

Processor Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 3.60 GHz
Installed RAM 16.0 GB

> The resulting VUPS values for x86-64 are now more realistic: 5900 VUPS on an i5-9600K CPU @3.7 GHz
>
> On this OpenVMS x86_64 system, PRIME_SIEVE needs 19.34 sec to calculate primes up to 10^10. On an ES45 Model 2B (EV68CB 1250 MHz) system it took 49.04 seconds, that system was measured at 2414 VUPS.
>
> See previous discussion in:
> https://groups.google.com/g/comp.os.vms/c/ouhZ7C7bgoQ/m/_iEqNzm1AwAJ
>
> PRIME_SIEVE was obtained from
> http://wwwhomes.uni-bielefeld.de/achim/prime_sieve.html
>
> Volker.

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

_______________________________________________
Info-vax mailing list
Info-vax@rbnsn.com
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

Mark Daniel schrieb am Donnerstag, 27. April 2023 um 15:31:26 UTC+2:

> |$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40
> |$ if f$getsyi("arch_name").eqs."x86_64" then $ cpu_multiplier=8

Mark,

we seem to be using different versions of the 'VUPS.COM' procedure ;-(
You seem to be using the one from FreeAXP, I'm using the one from Stromasys.

And therefore we cannot compare the results !

How about trying the PRIME_SIEVE.C example.

Volker.

On 2023-04-27, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
> On 27/4/2023 10:32 pm, Simon Clubley wrote:
>> On 2023-04-27, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>> Hi.
>>>
>>> Just saw this: https://wasd.vsm.com.au/info-WASD/2023/0077
>>>
>>>> TL;DR obvious profile differences in at least KERNEL mode
>>>> begs some questions about x86-64 VMS.
>>>>
>>>> This item is more about X86 VMS and less about WASD but
>>>> still uses WASD as a part of the measurement process.
>>>
>>
>> I couldn't see in the report whether the underlying x86-64 CPU running
>> the hypervisor was Intel or AMD.
>
> Processor Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 3.60 GHz
> Installed RAM 16.0 GB
>

Thank you Mark.

If those are the kernel figures for an Intel box, I would love to see
what they are for an AMD box...

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-27, Volker Halle <volker_halle@hotmail.com> wrote:
> Mark Daniel schrieb am Donnerstag, 27. April 2023 um 15:31:26 UTC+2:
>
>> |$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40
>> |$ if f$getsyi("arch_name").eqs."x86_64" then $ cpu_multiplier=8
>
> Mark,
>
> we seem to be using different versions of the 'VUPS.COM' procedure ;-(
> You seem to be using the one from FreeAXP, I'm using the one from Stromasys.
>
> And therefore we cannot compare the results !
>
> How about trying the PRIME_SIEVE.C example.
>

I've mentioned this before (and got some negative feedback for it
as everyone is focused on the CPU, not I/O), but I think some tests
that measure I/O performance using RMS (which will force a range of
mode transitions including through executive mode) may be interesting.

To make it a fair comparison, the I/O could be to a RAM disk so that
VMS overheads only are being compared.

Simon.

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

If you're wondering about kernel mode usage, try this:

$ ANA/SYS
SDA> READ/EXEC ! get better symbolization (routine names)
SDA> LOAD PCS ! PC sampling SDA Execlet
SDA> START TRACE
....
SDA> STOP TRACE
SDA> SHOW TRACE/STAT/MODE=KERNEL
....
SDA> UNLOAD PCS
SDA> EXIT

SHOW TRACE/STAT/MODE=KERNEL will show the PC values seen most often during the trace period (sorted by decreasing no. of occurences) and it will symbolize the PC values as routine names or execlet names. This might give you an idea, which kind of kernel mode code is running how often.

Volker.

If the system (servers, storage, connection infrastructure, etc) cannot do i/o at a reasonable rate, what good is it?
Coming from a manufacturing background, 'systems' not having good i/o rates were the key to how many widgets could be made.

On 28/4/2023 12:13 am, Volker Halle wrote:
> Mark Daniel schrieb am Donnerstag, 27. April 2023 um 15:31:26 UTC+2:
>
>> |$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40
>> |$ if f$getsyi("arch_name").eqs."x86_64" then $ cpu_multiplier=8
>
> Mark,
>
> we seem to be using different versions of the 'VUPS.COM' procedure ;-(
> You seem to be using the one from FreeAXP, I'm using the one from Stromasys.
>
> And therefore we cannot compare the results !
>
> How about trying the PRIME_SIEVE.C example.
>
> Volker.

Hi Volker.

I completely unsure of the provenance of the (calculate_)VUPS.COM I use
except it seems to have been around forever. I have placed what I have
been using at

https://wasd.vsm.com.au/other/vups.com

I searched for a stromasys.com version but was unable to locate it
either through the internet engine I use or via the Stromasys support page

https://www.stromasys.com/tools-resources

(though didn't try too hard).

I really didn't want another round of V9.2 metrics as with late last
year and only quoted the "VUPs" as indicative. The point of this
exercise was the very obvious difference in KERNEL mode consumption with
a very similar and diverse workload enabled via the ZAP+WASD crawl.

I was intending to ask a question in the VSI fora, pointing to these
results but Jan-Erik beat me to the punch in c.o.v. Will still do so.

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

On Thursday, April 27, 2023 at 7:05:29 AM UTC-4, Volker Halle wrote:
> Jan-Erik Söderholm schrieb am Donnerstag, 27. April 2023 um 11:24:46 UTC+2:
>
> After now also running a VSI OpenVMS x86-64 E9.2-1 system (using VMware Workstation Player 16) and installing the C compiler, I have tried to 'calibrate' the procedure to obtain the VUPS values for x86-64 using the PRIME_SIEVE.C tool (calculating prime numbers up to 10^10). The CPU_MULTIPLIER value for x86_64 should be set to 8 - you can easily edit this procedure to add (at the right place): $ IF F$GETSYI("ARCH_NAME").EQS."x86_64" THEN $ cpu_multiplier=8
>
> The resulting VUPS values for x86-64 are now more realistic: 5900 VUPS on an i5-9600K CPU @3.7 GHz
>
> On this OpenVMS x86_64 system, PRIME_SIEVE needs 19.34 sec to calculate primes up to 10^10. On an ES45 Model 2B (EV68CB 1250 MHz) system it took 49.04 seconds, that system was measured at 2414 VUPS.
>
> See previous discussion in: https://groups.google.com/g/comp.os.vms/c/ouhZ7C7bgoQ/m/_iEqNzm1AwAJ

I use the old Byte Magazine benchmark from the 1990s (bytemark, normalized to a 90Mhz Pentium). Running in on
my laptop under VirtualBox with an Intel i5-1235U gets an integer score 6-7 times higher than my DS10L/466 Alpha.
Interestingly, the floating point score is barely higher. Running the posted sieve code on both, the laptop is 11 times
faster.

At some point, I'll install visual studio on the laptop and see what difference the compiler makes. The current VSI
compiler is doing some optimization (unlike the cross compiler), as building with /opt=level=0 does slow it down.

On Thu, 2023-04-27 at 17:31 +0000, Simon Clubley wrote:
> If those are the kernel figures for an Intel box, I would love to see
> what they are for an AMD box...

Never mind, I see someone else has already posted a link, thanks.
--
Tactical Nuclear Kittens

On Thu, 2023-04-27 at 17:31 +0000, Simon Clubley wrote:
> If those are the kernel figures for an Intel box, I would love to see
> what they are for an AMD box...

Point me in the direction of a copy of VUPS.COM and I can run these
benchmarks.
--
Tactical Nuclear Kittens

Den 2023-04-27 kl. 19:58, skrev Mark Daniel:

> I really didn't want another round of V9.2 metrics as with late last year
> and only quoted the "VUPs" as indicative.  The point of this exercise was
> the very obvious difference in KERNEL mode consumption with a very similar
> and diverse workload enabled via the ZAP+WASD crawl.
>
> I was intending to ask a question in the VSI fora, pointing to these
> results but Jan-Erik beat me to the punch in c.o.v.  Will still do so.
>

Sorry. It was public on both the WASD site and on the WASD mailing list.
I did think for a while, but thought that it was intersting enough.

On 28/4/2023 7:00 am, Jan-Erik Söderholm wrote:
> Den 2023-04-27 kl. 19:58, skrev Mark Daniel:
>
>> I really didn't want another round of V9.2 metrics as with late last
>> year and only quoted the "VUPs" as indicative.  The point of this
>> exercise was the very obvious difference in KERNEL mode consumption
>> with a very similar and diverse workload enabled via the ZAP+WASD crawl.
>>
>> I was intending to ask a question in the VSI fora, pointing to these
>> results but Jan-Erik beat me to the punch in c.o.v.  Will still do so.
>>
>
> Sorry. It was public on both the WASD site and on the WASD mailing list.
> I did think for a while, but thought that it was intersting enough.

Apology absolutely, completely, unnecessary Jan-Erik.

And I certainly think it is interesting enough for the x86-64 VMS world.

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

On 28/4/2023 7:00 am, Jan-Erik Söderholm wrote:
> Den 2023-04-27 kl. 19:58, skrev Mark Daniel:
>
>> I really didn't want another round of V9.2 metrics as with late last
>> year and only quoted the "VUPs" as indicative.  The point of this
>> exercise was the very obvious difference in KERNEL mode consumption
>> with a very similar and diverse workload enabled via the ZAP+WASD crawl.
>>
>> I was intending to ask a question in the VSI fora, pointing to these
>> results but Jan-Erik beat me to the punch in c.o.v.  Will still do so.
>>
>
> Sorry. It was public on both the WASD site and on the WASD mailing list.
> I did think for a while, but thought that it was intersting enough.

Oh, and question asked:

https://forum.vmssoftware.com/viewtopic.php?f=21&t=8654

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

On Thu, 2023-04-27 at 17:31 +0000, Simon Clubley wrote:
> If those are the kernel figures for an Intel box, I would love to see
> what they are for an AMD box...

Using the VUPS.COM off that WASD link given earlier today:

$ @vups.com
innotek GmbH VirtualBox with 8 CPU and 16128MB running VMS E9.2-1
INFO: Preventing endless loop (10$) on fast CPUs
Approximate System VUPs Rating : 482.0 ( min: 482.0 max: 482.0 )

HTH.
--
Tactical Nuclear Kittens

On 4/27/2023 3:06 PM, David Jones wrote:
> I use the old Byte Magazine benchmark from the 1990s (bytemark, normalized to a 90Mhz Pentium). Running in on
> my laptop under VirtualBox with an Intel i5-1235U gets an integer score 6-7 times higher than my DS10L/466 Alpha.
> Interestingly, the floating point score is barely higher. Running the posted sieve code on both, the laptop is 11 times
> faster.

I use the code below which I not only have in C but also in
other languages.

Arne

native_test.c
=============

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>

#include "high_res_timer.h"

void printres(TIMECOUNT_T t1, TIMECOUNT_T t2, int n1, int n2, char *ops)
{ double xperf;
xperf = (double)n1 * (double)n2 / ((t2 - t1) * 1.0 / UNITS_PER_SECOND);
printf("%.2f million %s per second\n", xperf / 1000000, ops);
}

#define NINT 10000
#define NFP 1000
#define NSTR 100
#define N 1000000

void testint(int scale)
{ int i, j;
int nintscale, sum;
TIMECOUNT_T t1, t2;
nintscale = NINT / scale;
t1 = GET_TIMECOUNT;
for(i = 0; i < nintscale; i++)
{
sum = i;
for(j = 0; j < N; j++)
{
sum = ((sum + 1) * 2 + 1) / 2;
}
if(sum != (i + N))
{
printf("Integer test error\n");
exit(0);
}
}
t2 = GET_TIMECOUNT;
printres(t1, t2, nintscale, N, "integer operations");
}

void testfp(int scale)
{ int i, j;
int nfpscale;
double sum;
TIMECOUNT_T t1, t2;
nfpscale = NFP / scale;
t1 = GET_TIMECOUNT;
for(i = 0; i < nfpscale; i++)
{
sum = i;
for(j = 0; j < N; j++)
{
sum = ((sum + 1) * 2 + 1) / 2;
}
if(fabs(sum - (i + 1.5 * N)) > 1)
{
printf("Floating point test error\n");
exit(0);
}
}
t2 = GET_TIMECOUNT;
printres(t1, t2, nfpscale, N, "floating point operations");
}

#define ALFA "ABCDEFGHIJKLMNOPQRSTUVWXYZ"

void teststr(int scale)
{ int i, j;
int ix, ix1, ix2;
int nstrscale;
char s[1000], buf[N+1];
TIMECOUNT_T t1, t2;
nstrscale = NSTR / scale;
t1 = GET_TIMECOUNT;
for(i = 0; i < nstrscale; i++)
{
strcpy(buf, "");
for(j = 0; j < N; j = j + 10)
{
strcpy(s, ALFA);
strcat(s, ALFA);
ix = (i + j) % strlen(ALFA);
strncat(buf + j, s + ix, 1);
strncat(buf + j, s + ix + 1, 2);
strncat(buf + j, s + ix + 3, 3);
strncat(buf + j, s + ix + 6 , 4);
}
ix1 = N / 3;
ix2 = 2 * N / 3;
if(strlen(buf) != N || buf[ix1] != ALFA[(i + ix1) %
strlen(ALFA)] || buf[ix2] != ALFA[(i + ix2) % strlen(ALFA)])
{
printf("String test error\n");
exit(0);
}
}
t2 = GET_TIMECOUNT;
printres(t1, t2, nstrscale, N / 10, "string operations");
}

#define REP 10

int main(int argc, char *argv[])
{ int i;
int scale;
printf("%d bit\n", (int)(sizeof(char *) * 8));
if(argc > 1)
{
scale = atoi(argv[1]);
}
else
{
scale = 1;
}
for(i = 0; i < REP; i++)
{
testint(scale);
}
for(i = 0; i < REP; i++)
{
testfp(scale);
}
for(i = 0; i < REP; i++)
{
teststr(scale);
}
return 0;
}

high_res_timer.h
================

#if defined(__vms) && (defined(__alpha) || defined(__ia64))
#include <starlet.h>

static long long int vms_get_timecount(void)
{ long int res;
long long int t;
res = sys$gettim(&t);
return (res & 1 == 1) ? t : 0;
}

#define TIMECOUNT_T long long int
#define GET_TIMECOUNT vms_get_timecount()
#define UNITS_PER_SECOND 10000000
#endif

#ifdef __unix
#include <time.h>

static long long int unix_get_timecount(void)
{ int res;
struct timespec t;
res = clock_gettime(CLOCK_MONOTONIC, &t);
return (res == 0) ? (t.tv_sec * 1000000000LL + t.tv_nsec) : 0;
}

#define TIMECOUNT_T long long int
#define GET_TIMECOUNT unix_get_timecount()
#define UNITS_PER_SECOND 1000000000
#endif

#ifdef _WIN32
#include <windows.h>

static long long int win32_get_timecount(void)
{ BOOL res;
LARGE_INTEGER t;
res = QueryPerformanceCounter(&t);
return res ? t.QuadPart : 0;
}

static long long int win32_units_per_second(void)
{ BOOL res;
LARGE_INTEGER t;
res = QueryPerformanceFrequency(&t);
return res ? t.QuadPart : 0;
}

#define TIMECOUNT_T long long int
#define GET_TIMECOUNT win32_get_timecount()
#define UNITS_PER_SECOND win32_units_per_second()
#endif

#ifndef TIMECOUNT_T
#error "TIMECOUNT_T not defined"
#endif

#ifndef GET_TIMECOUNT
#error "GET_TIMECOUNT not defined"
#endif

#ifndef UNITS_PER_SECOND
#error "UNITS_PER_SECOND not defined"
#endif

Ok, I got updated VUPS.COM from WASD.

Here are results for i7-8700K processor (12 cores):

$ @vups2
innotek GmbH VirtualBox with 2 CPU and 7936MB running VMS E9.2-1
INFO: Preventing endless loop (10$) on fast CPUs
Approximate System VUPs Rating : 414.8 ( min: 408.4 max: 418.0 )
$

-----Original Message-----
From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Single Stage to
Orbit via Info-vax
Sent: Thursday, April 27, 2023 7:56 PM
To: info-vax@rbnsn.com
Cc: Single Stage to Orbit <alex.buell@munted.eu>
Subject: Re: [Info-vax] Some VMS/x86 perf test data from WASD maintainer.

On Thu, 2023-04-27 at 17:31 +0000, Simon Clubley wrote:
> If those are the kernel figures for an Intel box, I would love to see
> what they are for an AMD box...

Using the VUPS.COM off that WASD link given earlier today:

$ @vups.com
innotek GmbH VirtualBox with 8 CPU and 16128MB running VMS E9.2-1
INFO: Preventing endless loop (10$) on fast CPUs
Approximate System VUPs Rating : 482.0 ( min: 482.0 max: 482.0 )

HTH.
--
Tactical Nuclear Kittens

_______________________________________________
Info-vax mailing list
Info-vax@rbnsn.com
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

Also using the VUPS from WASD:

$ @wasd_vups
VMware, Inc. VMware7,1 with 4 CPU and 12028MB running VMS E9.2-1
INFO: Preventing endless loop (10$) on fast CPUs
INFO: Preventing endless loop (10$) on fast CPUs

Approximate System VUPs Rating : 693.1 ( min: 658.2 max: 705.6 )

The VM Host is an Intel NUC 9 Extreme NUC9i9QNX with 8 CPUs x Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz running ESXi V7.0u3 and 32GB memory

The OpenVMS VM is 4 vCPU with 12GB of memory.

John H. Reinhardt

On 4/27/2023 7:19 PM, fsword007@gmail.com wrote:
> Ok, I got updated VUPS.COM from WASD.
>
> Here are results for i7-8700K processor (12 cores):
>
> $ @vups2
> innotek GmbH VirtualBox with 2 CPU and 7936MB running VMS E9.2-1
> INFO: Preventing endless loop (10$) on fast CPUs
>
> Approximate System VUPs Rating : 414.8 ( min: 408.4 max: 418.0 )
> $
>
> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Single Stage to
> Orbit via Info-vax
> Sent: Thursday, April 27, 2023 7:56 PM
> To: info-vax@rbnsn.com
> Cc: Single Stage to Orbit <alex.buell@munted.eu>
> Subject: Re: [Info-vax] Some VMS/x86 perf test data from WASD maintainer.
>
> On Thu, 2023-04-27 at 17:31 +0000, Simon Clubley wrote:
>> If those are the kernel figures for an Intel box, I would love to see
>> what they are for an AMD box...
>
> Using the VUPS.COM off that WASD link given earlier today:
>
> $ @vups.com
> innotek GmbH VirtualBox with 8 CPU and 16128MB running VMS E9.2-1
> INFO: Preventing endless loop (10$) on fast CPUs
>
> Approximate System VUPs Rating : 482.0 ( min: 482.0 max: 482.0 )
>
> HTH.
> --
> Tactical Nuclear Kittens
>
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>
>

Mark,

there are at least 2 variants of the 'VUPS' procedure. And some of these variants have my name in them.

Stromasys variant: I have been using this variant since about 19 years in CHARON-VAX and CHARON-AXP migration projects. This procedure was supposed to report the 'correct VUPS' values as documented for the older real VAX and Alpha systems:

VUPS numbers for 'real systems' were publicized by DEC, but most of these documents have disappeared from the WEB.

Here are some examples: http://www.vaxmacro.de/vvcc.html

I had to modify the Stromasys VUPS procedure (called SRI_VUPS.COM at that time, SRI = Software Resources International, which later became Stromasys), because it would enter an endless loop on the faster Alphas (> 1 GHz). And this modification found it's way into the other variants below.

FreeAXP variant: http://www.migrationspecialties.com/Downloads/VUPS.txt
EmuVM variant: https://emuvm.com/download/vups-com-benchmark/

The above 2 are strongly related (as can be seen by this line: $ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40). And there is no code in these procedures to check the architecture they're running on and adapt the CPU_MULTIPLIER ! So the VUPS results produced can not be directly compared between the Stromasys variant and the other two - although there should be a linear relation between them. The DCL code in the 'inner loop' is the same for all these variants. Pure integer performance on one single CPU.

The idea of this procedure was the ability to compare 'VUPS' values between hardware systems and their emulated counterparts. Simple DCL procedure, could be mailed and run on the target system. No compiling required. When OpenVMS on I64 came around, I was interested in also calculating the 'VUPS' values for those systems. I used the runtime of the PRIME_SIEVE program to 'calibrate' the CPU_MODIFIER value in the SRI_VUPS.COM variant, so it would report VUPS values, which allowed to compare the VAX, Alpha, I64 and now x86-64 CPUs under OpenVMS.

So whenever someone provides VUPS values, they need to also document, which procedure has been used to collect them - as John has done by calling your procedure WASD_VUPS.COM

We can continue the VUPS discussion here, but should discuss the KERNEL mode question in the VSI forum.
Volker.

On 2023-04-27, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>
> And I certainly think it is interesting enough for the x86-64 VMS world.
>

It most certainly is Mark. I was expecting to see much higher overheads
for kernel mode because of the emulation overheads, but the kind of numbers
you have posted I was expecting to see on AMD boxes, not on Intel boxes.

That's why I am now interested in what the kernel mode overhead numbers
actually look like on AMD boxes.

Simon.

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