[Info-vax] VUPS.COM relevance for modern CPUs

[Arne Vajhøj]

On 12/16/2022 6:57 AM, Mark Daniel wrote:
> Now, before everyone piles on, I understand the procedure provides an 
> indicative/comparative/finger-in-the-air measurement of the relative 
> performance of a VMS CPU relative to "the original VAX processor".

Yes.

I think the order of preference would be:
1) measuring the actual application in question
2) measuring a board suite of programs (SPEC style)
3) measuring using a simple thing like this

But even the latter can do if it is only the magnitude that is
relevant.

> It seems to be implemented as a tight DCL loop that executes almost 
> entirely in inner modes (I'm sure Brian can explain why).
> 
> $ start_cputime = f$getjpi(0,"CPUTIM")
> $ loop_index = 0
> $ 10$:
> $ loop_index = loop_index + 1
> $ if loop_index .ne. init_loop_maximum then goto 10$
> $ end_cputime = f$getjpi(0,"CPUTIM")
> 
> |Combined for  2 CPUs         0         50        100       150      200
> | Interrupt State             |                                       |
> | MP Synchronization          |                                       |
> | Kernel Mode              21 |▒▒▒▒                                   |
> | Executive Mode           21 |▒▒▒▒                                   |
> | Supervisor Mode          58 |▒▒▒▒▒▒▒▒▒▒▒                            |
> | User Mode                   |                                       |
> | Compatibility Mode          |                                       |
> | Idle Time                99 |▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                    |
> 
> 100% (or all-but) of this execution appears to be in inner modes. 
> Although X86 (above) seems to to have much more Kernel than other 
> architectures, e.g. IA64 below).  There is no USER mode displayed in 
> either.
> 
> |Combined for  4 CPUs         0         100       200       300      400
> | Interrupt State           1 |                                       |
> | MP Synchronization          |                                       |
> | Kernel Mode               5 |                                       |
> | Executive Mode           18 |▒                                      |
> | Supervisor Mode          78 |▒▒▒▒▒▒▒                                |
> | User Mode                   |                                       |
> | Not Available               |                                       |
> | Idle Time               299 |▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒          |

Given that DCL runs in supervisor mode not user mode then supervisor
mode percentage being high and user mode being zero does not surprise
me.

I don't know why kernel and executive mode is higher on x86-64 than on
Itanium. But one possible explanation could be that kernel and executive
mode time is partly fixed while supervisor mode time (time spent
interpreting the execution of the loop) is strictly related to CPU
speed - which means higher K+E percentage and lower S percentage
on faster CPU's.

But a bit outside my area of expertise.

> There also appear to be earlier tweaks allowing for Alpha processors
> 
> |$ cpu_multiplier = 10 ! VAX = 10 - Alpha/AXP = 40
> |$ cpu_round_add = 1 ! VAX = 1 - Alpha/AXP = 9
> 
> but none for Itanium.
> 
> Are the Alpha tweaks sufficient to allow relevance for all 64bit CPUs?
> 
> Are further tweaks required to make measurements on Itania relevant?
> 
> And of course the same question for the successor to all three 
> architectures?

One would need to look at how those constants are used.

But if we assume that they make the test do more iterations
to provide a better test on faster systems (that is quite
common in speed tests), then I would expect Itanium
constants to be higher than Alpha constants and x86-64
constants to be higher than Itanium constants.

If they relate to something 32 bit vs 64 bit then the
previous would be totally wrong, but DCL is 32 bit math
AFAIK.

Arne