Hello,
my main object was the object caching facility for pure performance
reason. And as I wrote I don't even test it. All the debug and align
features was out of my mind. Only to get the object caching feature from
libumem is a little bloaty, I must admit. But maybe there is a realy
performance
Bert,
Reordering the members in the opal_class structure can be discussed.
In general, we don't focus on improving anything that's outside the
critical path (such as the class sub-system). Even if all Open MPI
objects are derived from this class, it is definitively not
performance aware,
This is a self fix reply
>
>
> ---
>
> opal/class/opal_object.c | 210
> +++
> opal/class/opal_object.h | 201
> 2 files changed,
Hello,
this gives the option to use the umem cache feature from the libumem[1]
for the opal object system.
It is full backward compatible to the old system.
But the patch exists of more changes:
(1) reorder opal_class_t, in the hope that vital members fit in the first
cache line
(2) a per c
