creating a objekt with an array linear in memory

[cody]

i basically want to create an object which contains an array (the last
element of the class).
the size of the array is determined when the object is created. for
performance reasons (avoiding cache misses) the whole objekt should be in
one linear chunk of memory, that is the array starts where the objekt ends
in memory.

class Cool
{
Cool (int arraysize) { .. }
char foo;
// more stuff goes here
float bar;
int[] myCoolArray; // that is the array where &myCoolArray==(&bar+1)
}

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no fucking ads]

 

[Gabriel Schreiber]

i basically want to create an object which contains an array (the last
element of the class).
the size of the array is determined when the object is created. for
performance reasons (avoiding cache misses) the whole objekt should be in
one linear chunk of memory, that is the array starts where the objekt ends
in memory.

class Cool
{
Cool (int arraysize) { .. }
char foo;
// more stuff goes here
float bar;
int[] myCoolArray; // that is the array where &myCoolArray==(&bar+1)
}

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no fucking ads]

Hy cody

I've just tried, but I haven't been able to figure it out exactly. But I
think it is done with the use of the placement new:

SomeType* = new (memory_position) SomeType;
or
SomeClass* = new (memory_position) SomeClass(parameter_list);
it does not allocate memory, but assumes, that at memory_position there
is just enough memory already allocated.
With this, you should be able to solve your problem.
(Allocate Memory, put Cool in the first part, the array in the second.)
I think it would be nice to overload the operator new of the class, but
that is where I got confused.

Gabriel

 

[Gianni Mariani]

i basically want to create an object which contains an array (the last
element of the class).
the size of the array is determined when the object is created. for
performance reasons (avoiding cache misses) the whole objekt should be in
one linear chunk of memory, that is the array starts where the objekt ends
in memory.

class Cool
{
Cool (int arraysize) { .. }
char foo;
// more stuff goes here
float bar;
int[] myCoolArray; // that is the array where &myCoolArray==(&bar+1)
}

This can be done but you've got work to do.

1. You can't create temporary versions of the object since the compiler
does not know the sice.

2. You have to prevent the compiler creating copies of the object into
temporaires that don't make sense.

3. You can't "new" the object, you'll need to use placement new.

4. You have to manage deleting the object ALL the time. The compiler
can't do it for you.

5. If the array type is a non-trivial class, you will need to manage
the constructors and destructors of those objects.

6. You need to make sure you can avoid copying the object.

.... lots of work.

How much work have you done to determine the cost of cache misses on
your particular appllication ? I'm very interested in performance
issues and so I'd like to know how you arrived determining you need to
do this.

G

 

[cody]

This can be done but you've got work to do.

1. You can't create temporary versions of the object since the compiler
does not know the sice.

2. You have to prevent the compiler creating copies of the object into
temporaires that don't make sense.

no problem, create a copy ctor and make it private.

3. You can't "new" the object, you'll need to use placement new.

4. You have to manage deleting the object ALL the time. The compiler
can't do it for you.

the dtor will know what to delete since i could pass the byte chunk where
the object is placed in to the ctor.

5. If the array type is a non-trivial class, you will need to manage
the constructors and destructors of those objects.

6. You need to make sure you can avoid copying the object.

... lots of work.

i imagine that it will be relatively simple.

How much work have you done to determine the cost of cache misses on
your particular appllication ? I'm very interested in performance
issues and so I'd like to know how you arrived determining you need to
do this.

i have to traverse all the objects vers fast and go through its array, too.
so it was just my guess that here could lots of cache misses occur.

 

[Gianni Mariani]

i imagine that it will be relatively simple.

This is far simpler - it's also finished.

class Cool
{
Cool (int arraysize) { .. }
char foo;
// more stuff goes here
float bar;

i have to traverse all the objects vers fast and go through its array, too.
so it was just my guess that here could lots of cache misses occur.

But have you tried without it yet ?

The code above may be all you need for your code to run acceptably and
it may actually have BETTER cache characteristics than you might think.

Is the code already running ?

 

[Kevin Goodsell]

i have to traverse all the objects vers fast and go through its array, too.
so it was just my guess that here could lots of cache misses occur.

"Programmer's Intuition" is a bad way of determining what and when to
optimize. I strongly recommend using Gianni's vector solution, and
updating it to something faster later *IF* you determine it's necessary
and *after* you've debugged the program.

Note that the "if it's necessary" criteria is only met after you
determine that 1) the program's overall performance is insufficient and
2) the section in question is a major source of inefficiency (measure,
don't guess).

-Kevin

 

[cody]

This is far simpler - it's also finished.

class Cool
{
Cool (int arraysize) { .. }
char foo;
// more stuff goes here
float bar;
vector<int> myCoolArray;
}

sorry but i dont understand why the vector should more performant than an
array? imho a vector is internally simply an array.

the second reason why i want the objects to be linear is to avoid memory
fragmentation, because i have to create lots of these objects.
after several iterations through all objects some of them have to die and
new ones (with different sizes) must be created.
thats why iam concerned about cache misses and memory fragmentation.

 

[Kevin Goodsell]

sorry but i dont understand why the vector should more performant than an
array? imho a vector is internally simply an array.

the second reason why i want the objects to be linear is to avoid memory
fragmentation, because i have to create lots of these objects.
after several iterations through all objects some of them have to die and
new ones (with different sizes) must be created.

Then how do you expect to avoid memory fragmentation?

thats why iam concerned about cache misses and memory fragmentation.

You really, really should worry about making the program *work* first.

-Kevin

 

[C Wood]

: > This is far simpler - it's also finished.
: >
: > class Cool
: > {
: > Cool (int arraysize) { .. }
: > char foo;
: > // more stuff goes here
: > float bar;
: > vector<int> myCoolArray;
: > }
: >
:
:
: sorry but i dont understand why the vector should more performant than an
: array? imho a vector is internally simply an array.
:
: the second reason why i want the objects to be linear is to avoid memory
: fragmentation, because i have to create lots of these objects.
: after several iterations through all objects some of them have to die and
: new ones (with different sizes) must be created.
: thats why iam concerned about cache misses and memory fragmentation.

Really, as the other poster said, you should make it work first.

Then, if you can prove that it's getting fragmented, then you'll need
your own custom new operator.

But, if you are doing what you said, (alloc/dealloc x 8...) over and
over, then you shuold be concerned if this program is to run longer than an
hour (other whatever number of iterations that's epected).

Basically new a new chunk of memory, then placement new each "new"
inside of it, keeping track of fragmentation. In an operation where I do
something like this myself, I use memcpy to compact them, and update all the
pointer locations and such. have to slide or memcpy the elements around to
get more space occasionally. I call the compact function when the space
available is less than needed (contigous) by the totally space available is
larger than needed... IOWs:

11111111...222222...444........33333333333....5555555555555...
(. is free space)

becomes

1111111122224433333333333555555555..................................

It works well, and runs non-stop for months, and does not corrupt the
free store. (Aka fragment)












: