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

[johnwallace4 at yahoo.co.uk]

On Saturday, 28 March 2020 16:02:52 UTC, 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.

Performance of encryption code on modern RISC processors (which 
obviously excludes IA64) can depend on a variety of "interesting"
things waiting to trap the innocent. The same comment can apply to
other kinds of code too, but encryption is one of the few that led 
to later-life changes to the Alpha instruction set. Those changes
were *after* the time of the PWS500, if I remember rightly.

At the moment I can't add much more than that (time is not on my
side just now, what with coronavirus responses and such delights).

The stuff I'm thinking about was published/public info so *maybe* 
others will have better memories than me.

TL;DR: Here be dragons. And probably dinosaurs.