language choices for aggregation

[Frank Ch. Eigler]

Hi -


hunt wrote:

> I assume the efficiency increases are due to using per-cpu data then
> combining that at probe exit?

Correct.

> If the aggregation is a vector, we currently aren't going to see any
> efficiency increase because the map will have to be locked. [...]

Not quite - one plausible implementation is for the translator to
create parallel per-cpu map objects, and not apply locking to them at
all.

> [...]  It is cheap to track them all. 

Perhaps so, for the simple aggregates.

> That's what the maps do now.

Yes, but I don't consider it clear that the map routines should deal
with statistics at all, as distinct from an opaque value type that
they copy (like my old templating-based variable-arity map prototype
did).  After all, statistics could be simple scalar values.

> So then anything that uses "<<<"  is an aggregate that tracks count,
> sum, min, and max. Histograms are more complex and will need to be
> declared.
> [...]
> var: count=1234 sum=134059 avg=108.6 min=5 max=311
> 0  ** 
> 10 **********
> [...]

In the interest of compactness, it would be nice not to print much
data that is not known to be of interest to the user.  This could be
another argument for not automagically computing all simple
aggregates.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050502/876afd88/attachment.sig>