[Info-vax] High resolution per-process CPU consumption statistics

[Mark Daniel]

On 25/3/20 7:58 am, johnwallace4 at yahoo.co.uk wrote:
> On Tuesday, 24 March 2020 17:05:24 UTC, Mark Daniel  wrote:
>> On 24/3/20 9:24 pm, johnwallace4 at yahoo.co.uk wrote:
>>> On Tuesday, 24 March 2020 00:02:22 UTC, Mark Daniel  wrote:
>>>> Would like to be able to measure process CPU consumed during specified
>>>> continuous sections of processing.  Only interested in CPU-intensive
>>>> sections so USER mode consumed relevant.  Imagine inserting calls at the
>>>> beginning and ending of those sections with a magic number representing
>>>> CPU consumption/delta/whatever made available.
>>>>
>>>> As some of these CPU-intensive code sections are short duration the
>>>> granularity needs to be quite fine.  The likes of JPI$_CPUTIM and
>>>> LIB$STAT_TIMER (10mS) seem unsuitable.
>>>>
>>>> Prepared for non- USER mode code.  This is only for ad hoc developmental
>>>> insight and not general use.  Needs to accommodate Alpha and/or Itanium
>>>> (and/or x86-64 :-)
>>>>
>>>> And, of course, any other suggestion.
>>>>
>>>> As always, TIA.
>>>
>>> Is it safe to assume that the code in question is single-threaded?
>>
>> Yes.
>>
>>> Is it safe to assume that the code in question is running on a
>>> single-processor system?
>>
>> Yes.
>>
>>> Is an Alpha-only solution better than nothing at all?
>>
>> Sure.
>>
>>> Have a look at RPCC (Read Process Cycle Counter) in the Alpha/VMS
>>> PALcode and see if it might help.
>>>
>>> See e.g. the Alpha Architecture Reference Manual documentation e.g.
>>> http://www.bitsavers.org/pdf/dec/alpha/Sites_AlphaArchitectureReferenceManual_1992.pdf
>>> (there's probably more useful RPCC-related stuff available too).
>>
>> Before posting here, a fair effort with an unnamed but common search
>> engine and my chosen query strings consistently returned references to
>> that document and section.
>>
>> My fevered imagination (but internals hacking very-much limited to
>> monkey-see-monkey-do) has something of the ilk:
>>
>>      unsigned __int64  start_count,
>>                        end_count;
>>
>>      void get_cpu_count (unsigned __int64 *here)
>>      {
>>         *here = EXE$GL_CURRENT_CPU_COUNT;
>>         return SS$_NORMAL;
>>      }
>>
>>      sys$cmkrnl (&get_cpu_count, &start_count);
>>      ...
>>      sys$cmkrnl (&get_cpu_count, &end_count);
>>
>> Some similar code would be used to obtain the RPCC.
>>
>> Thanks for the suggestion John.
> 
> I only offered half a suggestion :( (bit pushed for time
> earlier).
> 
> Now I'm back and I have clarity on some of your constraints,
> I'll try to improve my suggestion.
> 
> Are you writing in C, or do you have access to a C compiler?

Yes.

> If you have access to Compac C (or similar) for Alpha,
> and/or related documentation, have a look at the __RPCC(void)
> builtin. No programming required (almost).

A bored VMS kernel hacker pipped you (just) at the post.

> This from the HP C Users Guide for OpenVMS; other decuments
> and/or compilers may be relevant
> 
> ///
> 
> 6.2.1.90 Read Process Cycle Counter ( __RPCC)
> 
> The __RPCC function reads the current process cycle counter.
> 
> This function has the following format:
> 
> uint64 __RPCC (void);
> 
> ///

Upon reading Brian's post, seeing it looked like a SYS$ routine, I 
searched specifically for that.  Voila!

The document says "Alpha and Integrity Servers".  So looks like good for 
64 bit VMS (presumably including x86-64).  Undoubtedly the underlying 
implementation varies.

> It is left as an exercise for the student to work out how
> this is implemented, e.g. specifically how to use it from
> non-C code (meaning: I used to know, but it's a long time
> since I used it and a LOT of memory has become volatile
> and error-prone in the intervening years).
> 
> You can probably work out how to put another layer on top
> to make it a closer fit to your particular needs so you
> can for example generate output along the lines of:
> 
> Code block 7 executed 59 times, total 4194303 cycles,
>   minimum time: 3 cycles, maximum 47000 cycles.
> 
> Or whatever. I'm sure you get the general idea.

Give a (code-)monkey an example...

> Can you say a little more about what you're trying to
> achieve here? It may not be appropriate to extrapolate
> results among different members of the Alpha family,
> never mind from one processor architecture to a very
> different one (Alpha->IA64?). Maybe that doesn't
> matter?

Understanding the *proportional* overhead of cryptographic processing on 
top of everything else will be sufficiently fit-for-purpose.  Absolute 
metrics much less important.

And it could be done by measuring the time /n/ transactions unencrypted 
vs the same number encrypted took to process but I thought I'd try this 
first.  Might even show some portions more intensive than others.

Thanks again Brian and John.

> Have a lot of fun.

Trying.