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

[Andreas Gruhl]

Mark Daniel schrieb am Montag, 19. Dezember 2022 um 06:01:45 UTC+1:
> On 17/12/2022 10:13 am, Mark Daniel wrote: 
> > On 16/12/2022 10:27 pm, 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". 
> > 8< snip 8< 
> > 
> > Thanks to all those who contributed to this thread. 
> > 
> > The followup that caught my eye was from Simon Clubley who provided an 
> > entirely convincing explanation for the elevated X86 Kernel mode. 
> > 
> > Also his pointer to BogoMips.  Most interesting.  I read the FAQ and 
> > accessed the github code.  Quite straighforward.  Might be a good 
> > replacement as a general performance metric. 
> > 
> > https://github.com/vitalyvch/Bogo/blob/BogoMIPS_v1.3/bogomips.c
> 8< snip 8< 
> 
> For general VMS comparative usage something more VMS-measuring is 
> needed. I looked about the 'net and nothing sprang out. I wonder what 
> VSI are using for metrics on X86 development? Anything lurking in the 
> DECUS/Freeware repositories I missed? 
> 
> Anyway, in the absence of anything else, I was thinking about what may 
> consume "non-productive" VMS cycles (i.e. non-USER mode crunching :-) 
> and all I could think of were the transitions between USER, EXEC and 
> KERNEL modes. As required by RMS, $QIO, drivers, etc., etc. No SUPER 
> modes measured here. 
> 
> With this in mind I knocked-up a small program to repeatedly call a 
> function using $CMEXEC which calls a function using $CMKRNL and that is 
> that. It measures how much effort is required compared to the simple 
> USER mode loop and reports it as b[ogo]VUPs. 
> 
> https://wasd.vsm.com.au/wasd_tmp/bogovups.c 
> 
> The real disappointment is my X86 VM. The rest of the results seem in 
> line with expectations. 
> 
> PS. Looking for ideas, suggestions, criticism(s), etc. here...
> -- 
I ran your program in two of our own environments with the following rsults:

|AlphaServer ES45 Model 1B 4 CPUs 16384MB V8.4-2L2
|Calculating IPS...
|321.000000 cpu-ticks, 3.279087 seconds, 609925873 / second
|Calculating bVUPs...
|1645.000000 cpu-ticks, 16.614445 seconds, 370.8 bVUPs
|9157.000000 cpu-ticks, 91.599084 seconds, 10.8 bVUPs

|HP DL380 2.6 GHz VMware, Inc. 4 CPUs 15868MB V9.2
|Calculating IPS...
|459.000000 cpu-ticks, 4.589954 seconds, 435734205 / second
|Calculating bVUPs...
|7470.000000 cpu-ticks, 74.799252 seconds, 58.3 bVUPs
 
Sorry to say, but your bVUPs computation is not very useful.
This is because you divide dins [instructions/sec] by dticks [0.01 sec].
Insead of being dimensionless (like a good VUP ought to be)
your result has the physical unit of [ 1/sec²].
My own interpretation of the figures given above is:
X86 integer performance reaches 71% of ES45 (321/459 Ticks)
X86 change mode performance reaches 22% of ES45 (1645/7470 Ticks)

This not bad given the fact, that the C crosscompiler currently attempts no
optimization at all (as I know from an extraordinarily well informed source).
Andreas