On Wed, 3 Aug 2016, John Peterson wrote:
On Wed, Aug 3, 2016 at 10:22 AM, Derek Gaston <fried...@gmail.com> wrote:
> Related to my other email... another thing that would allow us to do a LOT of
optimization is if we had
> a free void pointer on DofObject. This would allow us to attach any kind of
data structure we want for
> caching computations on DofObject (for instance: caching the value of shape
functions at the quadrature
> points!).
I see this as a compile time option (that is off by default) because it
obviously adds a bit of memory
overhead.
Agreed - I definitely don't want another 8 bytes per DofObject enabled
by default, but I would like users to be able to attach per-DofObject
data without having to maintain separate containers.
> Note: for the kinds of optimizations I'm talking about I don't even
> want a log(n) lookup in a map
Agreed.
> or the complexity of a hash computation for a hash-map.
You mean O(1)? ;-)
Can we not make it a pointer to a "Context" class with basically
nothing (or some very minimal interface) in it that people can
derive from and doesn't prevent you from doing what you want to do?
I was about to say that the "minimal interface" for arbitrary
user-defined data *is* "void".
On the other hand, it would be pretty sweet to require the user to
implement serialize/unserialize methods, and thereby make all our
packed_range stuff continue to work seamlessly even with user data
attached.
Another possiblity we discussed offline: allow the addition of user
data via a member whose type is a template parameter. The benefit
would be efficiency: instead of adding your data plus 8 bytes plus
heap allocator overhead to each DofObject, you would add just your
data to each DofObject, and having the data right there would probably
help cache access patterns too. This would also allow us to make user
data an efficient run-time option; by default DofObject subclass
construction would instantiate versions where the user data type was
void.
---
Roy
------------------------------------------------------------------------------
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
