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

[Mark Daniel]

On 25/3/20 9:21 am, VAXman- at SendSpamHere.ORG wrote:
> In article <e9e7b8c6-b229-4504-9859-85b33912de30 at googlegroups.com>, johnwallace4 at yahoo.co.uk writes:
>> 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;
> ------------------^^^^^^^^^^^^^^^^^^^^^^^^
> Where do you resolve this???

It is a code-point in that same imagination Brian.

"... of the ilk", wasn't the giveaway?  Cheers.