This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: major runtime map changes


Hi -

hunt wrote:

> [...]
> > OK.  Maybe it will be useful to avoid such copying, and do it
> > virtually, something like this:
> > - [3 algorithms]
> 
> That is much more complex than what I proposed and all it does is save
> some storage space. 

In addition, it saves copying and metadata churn (rehashing, reallocation).

> Sorts become a huge mess; it is not as easy as you make it sound.

(I'm somewhat curious what extra complications you forsee.  Remember,
sorting is interesting only for purposes of consequent iteration.)

> And we also lose the ability to just call a simple aggregation
> function and then treat the output exactly as a normal map, reusing
> all the current map functions.

If it turns out that the pmap api is not too far from the map api, the
translator will have no trouble with either.

> While I'm thinking about it, do we want to preserve the per-cpu
> data?  [...]  If we do not want per-cpu data kept, then we have an
> option of having the local maps cleared after each aggregation
> operation [...]

That could work well, if it turned out that aggregates were not
aggregated frequently.  :-)  What I mean is that if the access 
is like

   var[idx] <<< exp

and [idx] reoccurs a lot (which it should - that's the whole point),
then there is a cost to clearing the per-cpu table: the reallocation
of the same index tuple at the next "<<<".


Anyway, Graydon and I are talking over the whole statistics issue.  It
may be that all we will end up needing from the runtime are ordinary
maps that store binary blob values of some initialization-time-fixed
width.  It would leave all the mathematics etc. to be open-coded by
the translator, or else added to new runtime sources.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]