[cpo-proposal] About mixout container for polymorphic objects
Hi all,
I have design a new concept of container to be part of the cpo library.
In summary, those containers will break down the inserted objects into
some elementary parts.
Why do that?
Short answer: to save memory.
Long answer: Because the alignment requirement of data members
in an object could be very different, in a range from 1 byte to 16 bytes,
structs or classes use padding to provide the correct location for members.
That means an object size could be significantly greater than the sum
of its members sizes. Even more, when dealing with polymorphic objects,
the size is increased a little more due to the pointer to the table
of virtual methods.
I will try to outline the alternative solution, obviously, the implementation
will be part of the container, the user will not need to know the details.
---- Example:-----
#include <cstdlib>
#include <iostream>
#include <vector>
class output
{
public:
virtual void print(std::ostream& out) = 0;
};
class integer {
public:
integer(short a_ = 0) : a(a_) { }
short a;
};
class character {
public:
character(char c_ = 'a') : c(c_) { }
char c;
};
class data {
public:
data(double x_ = 0) : x(x_) { }
double x;
};
class my_object :
public integer,
public data,
public character,
public output
{
public:
my_object(int show = 1)
: integer(rand() % 100)
, data(1.0*rand()/RAND_MAX)
, character('a' + rand() % 10)
{
if (show) print(std::cout);
}
virtual void print(std::ostream& out)
{
std::cout << a << "\t" << x << " \t" << c << "\n";
}
};
void insert( std::vector<integer>& v_int,
std::vector<data>& v_data,
std::vector<character>& v_char,
const my_object& o)
{
v_int.push_back( o );
v_data.push_back( o );
v_char.push_back( o );
}
void iterate( std::vector<integer>& v_int,
std::vector<data>& v_data,
std::vector<character>& v_char
)
{
my_object o(0);
unsigned i;
for ( i = 0; i < v_int.size(); ++i)
{
static_cast
On Sep 17, 2013 4:46 PM, "Santiago Tapia"
Hi all,
I have design a new concept of container to be part of the cpo library.
In summary, those containers will break down the inserted objects into some elementary parts.
Why do that? Short answer: to save memory.
I do believe this will also kill the cache in most cases.
On 17-09-2013 14:58, yuri kilochek wrote:
On Sep 17, 2013 4:46 PM, "Santiago Tapia"
wrote: Hi all,
I have design a new concept of container to be part of the cpo library.
In summary, those containers will break down the inserted objects into some elementary parts.
Why do that? Short answer: to save memory.
I do believe this will also kill the cache in most cases.
For my application at least, the contained objects will be much larger than the padding. So if that is what worries you, I don't think it should. -Thorsten
On Tue, Sep 17, 2013 at 4:58 PM, yuri kilochek
On Sep 17, 2013 4:46 PM, "Santiago Tapia"
wrote: Hi all,
I have design a new concept of container to be part of the cpo library.
In summary, those containers will break down the inserted objects into some elementary parts.
Why do that? Short answer: to save memory.
I do believe this will also kill the cache in most cases.
It depends on data processing pattern. If this container performs AoS <-> SoA transformation, it can be useful for parallel/vectorized data processing. However, I don't see how this container could be implemented generically for arbitrary types. I would be interested to see such implementation.
On 17/09/13 16:11, Andrey Semashev wrote:
It depends on data processing pattern. If this container performs AoS <-> SoA transformation, it can be useful for parallel/vectorized data processing. However, I don't see how this container could be implemented generically for arbitrary types. I would be interested to see such implementation.
The library I work on, NT2, already does this for vectorization purposes. It works for any Fusion Sequence (i.e. any type that offers a tuple-like interface to iterate the members).
participants (5)
-
Andrey Semashev
-
Mathias Gaunard
-
Santiago Tapia
-
Thorsten Ottosen
-
yuri kilochek