Re: RFC: major runtime map changes

[Martin Hunt <hunt at redhat dot com>]

On Tue, 2005-10-25 at 21:08 -0400, Frank Ch. Eigler wrote:
> [...]
> > 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.)

If you are sorting based on keys, then your proposal works fine.  But
the more useful case will be sorting based on aggregated values, in
which case your proposal of sorting each per-cpu map is just a waste of
time.

> > 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.

It will be almost identical.

> > 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 "<<<".

Reallocation consists of removing a node from the head of one list and
inserting it at the end of two others, which is just some pointer
manipulation.  The bigger cost is copying the keys into the node, which
might be strings. 

> 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.

I don't understand why you wouldn't want common code like that in the
runtime. 

Martin