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

[chris]

On 12/20/22 13:56, Andreas Gruhl wrote:
> 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

None of this makes much sense. spec.org have been devising cpu tests
for decades and have specialist tests for different workloads. That
includes all the info on compilers and code used. Probably the most
accurate data around and is supported by system and cpu vendors as
well. Too many variables involved, so some sort of level playing
field approach is the only way to get accuracy.

Can be fun devising simple tests, but would never used that as a
basis for purchasing decisions...

Chris