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

[hb]

On 3/28/20 5:02 PM, Mark Daniel wrote:
> On 25/3/20 8:42 am, Mark Daniel wrote:
>> 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.
> 8< snip 8<
>>> 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.
> 
> A brief update:  On Alpha V8.3 and PWS500.  The SYS$RPCC_64 call works 
> and returns some *very* large numbers/deltas even inside otherwise 
> single 10mS time intervals.  Some code wrapped around it provides those 
> deltas and the percentages of totals.  Perversely, it seems a little too 
> fine-grained for my initial needs.  Would be perfect for comparing 
> efficiencies of alternate tight code blocks.  Might be heading back in 
> the direction of /n/ transaction comparisons but will to continue to 
> experiment.

Very large numbers? As far as I know the counter you want is a 32-bit 
value. Did you do the shifts and add? I assume they are explained in the 
Alpha architecture manual.

#include <stdio.h>
#include <unistd.h>
#include <builtins.h>

int main(void) {
         unsigned __int64 pcc;
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         printf ("sleep(1)\n");
         sleep(1);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         printf ("sleep(4)\n");
         sleep(4);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc= ((pcc<<32)+pcc)>>32;
         printf ("0x%016llx\n", pcc);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc= ((pcc<<32)+pcc)>>32;
         printf ("0x%016llx\n", pcc);
         printf ("sleep(1)\n");
         sleep(1);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc= ((pcc<<32)+pcc)>>32;
         printf ("0x%016llx\n", pcc);
         printf ("sleep(4)\n");
         sleep(4);
         pcc=__RPCC();
         printf ("0x%016llx\n", pcc);
         pcc= ((pcc<<32)+pcc)>>32;
         printf ("0x%016llx\n", pcc);
         return 0;
}