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

[Craig A. Berry]

On 12/18/22 11:01 PM, Mark Daniel wrote:
> 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...

It's pretty hard to know what this means, if anything.  I'll assume your
VirtualBox host is a speedy recent Intel machine with all the cpu
capabilities VMS prefers?  (not an M1 Mac emulating x86 I hope!).

It may be that the cross compiler doesn't have optimizations turned on.
It may be that there is a ton of debugging code in the OS that will
eventually get turned off.  It may be mode switching is genuinely slow
on x86.

If the latter is the main culprit, I suspect it will play out the same
way alignment faults did on Itanium.  They were horrible for the things
affected, but not everything was affected, and not everything that was
affected was affected equally.  And multiple different fixes to
compilers, products, and the OS itself eventually mitigated them to
where they became a non-problem for most people most of the time, but it
took a couple years.

The last time I remember anyone from VSI saying anything about
performance was that they hadn't even started looking at it yet.  That
may have been over a year ago, but I suspect they still haven't -- just
too much else to do.  The word "performance" does not appear on the roadmap.

Somehow I got the impression that enabling compiler optimizations would
be deferred until after native compilers were available.  (I may have
that wrong, possibly from a vague memory of the order in which things
happened for previous ports). Not that one couldn't enable optimizations
in a cross compiler, but just that they are working in priority order,
and having native compilers (and more compilers, such as BASIC) is a
much higher priority than performance at this point.  You can't even
port from Alpha to x86 right now without buying an Itanium, and I doubt
very many Alpha customers would consider doing that.