Re: [Boost-users] Flyweight: wrapping shared_ptr

Subject: Re: [Boost-users] Flyweight: wrapping shared_ptr
From: Akim Demaille (akim_at_[hidden])
Date: 2014-10-10 04:31:24

Le 9 oct. 2014 à 22:20, Joaquin M Lopez Munoz <joaquin_at_[hidden]> a écrit :

> This is what's hapenning:
> 
> 1. make(v) creates a *temporary* flyweight(v), which contains a
> make_num struct containing a std::shared_ptr<Num_impl>.

Ah, yes, of course.  Thanks.  This is fixed now.

> Why do you want to have a factory per node type?

To be able to try it and to bench it.  I'd like to be sure about the
choice to make wrt the overhaul of my ASTs, and the options I have so
far seem to be:

a. a single factory based on Flyweight, and use derived_poly_flyweight

b. one factory made by hand on top of map or unordered_map

c. likewise, but with Flyweight and key_value

> Hash containers'
> performance is basically independent of the number of elements being
> contained, so you won't get any significant speedup by separating
> types --what's more, you can even get a performance reduction
> due to CPU cache misses, since having more hashed containers around
> places more bucket arrays in the program's working memory.

Well, this is not so clear to me, as the expressions I store
have often a strong regularity, with many elements of the
same kind in a row.

Besides, I appreciate that I can get rid of one level of indirection,
as the factories now store genuine objects, not pointers to them.
And I expect this to have quite a positive impact on the performances.

b features this, and has the advantage that there are fewer types
to deal with in the library: it's just shared_ptr and that's something
people know.  But actually b does not work properly yet, and I probably
have to deal with ref-counting myself, because the version which is
in the store should not count.

There are contributors and users of this library, so I am also concerned
with the learning curve for people who would want to use it.  Yet
speed is a primary concern.  Since eventually we will certainly go
parallel, I also appreciate Flyweight's safety.

So really, I'd like to have toy implementations of a, b, and c, and
them decide what to do (well, discuss with the other members and see
what conclusion emerges).

I feel that Boost.Flyweight has everything I need: it keeps the right
ref counter, can support key-value map, it is safe, well documented etc.
Yet I have to find a means to get polymorphism back in business.