Big arrays and memory

[ZED0815]

I've got a question for you here: what's the best way creating a huge array of (quite) big objects ...I've got a class consisting of like 30 double precision values, which would make the array's type. So the whole array will be at least 100*100*100*30*sizeof(double).

myBigClassType *** myClass;
myClass = new myBigClassType**[x];
for( x=0... and so on for y and z respectively

or do like:

myBigClassType * myClass;
myClass = new myBigClassType[x*y*z];

I think - but might be wrong - that the second statement just works fine if there is a huge chunk of de-fragmented memory available - big enough to take the whole big array, whereas the former declaration just needs one line (z-dimension) of de-fragmented memory and can actually place different parts of the array on different memory spaces - correct? So the first way should be better right?

[ZED0815]

Anyone?

[Syuf]

I think, that the first is easier and more comfortable to use, but it needs the extra memory to store (1 + x*y) pointers (4 or 8 bytes each), also there is no such danger connected with the memory fragmentation (I think it really influence on success of memory allocation here), but it works a bit slower, because it needs to count 3 dimensions to access an element in the array, but the second variant needs only one.

[webJose]

I think you've answered yourself there. You clearly know the implications of the latter statement and the advantage of the former. Now pick. What factors can you account for in your selection? The targeted machine for once. If the machine will be a 64-bit platform with lots of RAM, maybe you can go with the latter rather easily.

Now you should also ask yourself this: Is the program going to need fast access to all array elements? Or can you write chunks to a temporary file and just load them on demand?

[ZED0815]

Yes the faster the better...the bottleneck of my simulation is clearly RAM access, and this sums up to several days of computational time on a 12 core node. (My last attemp at least - currently I'm working on a new attempt implementing OMP instead of POSIX threads, which hopefully will gain some speed...and get rid of old C fragments...)

[ZED0815]

Ok thank you both! I think I got the idea...I'm afraid it was not all that obviously for me why the former way is a bit slower, but thinking about it, you're clearly right: following three pointers is obviously a bit more work than going for the first one directly!

Thanks!