dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Friday January 27 2012 10:11:07 Joachim Berdal Haga wrote:
> On 26 January 2012 22:40, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Wed, Jan 25, 2012 at 03:21:12PM +0100, Joachim Berdal Haga wrote:
> >> This seems to be because of the instantiation of boost::shared_arrays.
> >> The ownership of the array data is not transferred (the data will be
> >> deleted by the caller of evaluate()), so this does not really add any
> >> safety.
> >> 
> >> I don't have a complete picture of how Array<> is used, does the
> >> Python layer rely on the shared semantics (in other places)? If not,
> >> it might be better to make them non-shared and create copies for use
> >> in Python where needed.
> > 
> > Would it help if we do this:
> > 
> > 1. Make GenericFunction::evaluate an inline function that just calls
> >   a new version of GenericFunction::eval.
> > 
> > 2. The new version of GenericFunction::eval has the same
> >   implementation as the current evaluate() function.
> > 
> > The result would be that we get two eval() functions, one with plain
> > pointers and one with Array(). A C++ user (and the JIT-compiled
> > expressions) would use the plain pointer version, while the Array
> > version gets wrapped for Python subclassing (where I assume the extra
> > cost will not make a difference).
> 
> I'm unsure about the details of how much of the call tree would have
> to get dual signatures, but I guess it would be possible. However, it
> doesn't add any safety for the Python layer because the data will be
> deleted by the C++ layer even if Python holds a (shared) reference.
> And as Johan says, the different interfaces are a maintenance problem.
> 
> In my opinion, it would be best to make Array<T> a simple T*/len
> container, and either subclass it or add a flag to decide if it owns
> the data. Then, for sharing, use shared_ptr<Array>, and add some
> safeguards that the shared_ptr actually holds an owned array.

Are you looking into this Joachim? Maybe you can try to implement a new 
storage pattern, and check the performance of that?

Johan
 
> -j.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp