Thread: fastest way of passing data to a class

hey

I'm currently building a new data structures that will be used in monte carlo generators (and so will be constructed several milion times) and I'm wondering what's the best way (computer-speed-wise) to pass the data to the constructor.

I am currently doing it using references and passing arrays as pointers like this:

Code:

class particle{
public:
    particle(double *ar,int &id):IDup(id){
        for (int i=0;i<5;++i)
            Pup[i]=ar[i];
    }
	int IDup;
	double Pup[5];
};

I'm assuming that since using referencies has no need to create a temporary memory slot it's more efficient (if there is a better way, I'm all ears).

As for the arrays: is there a way for me to pass them as reference as well? (not using c++11), I'm using arrays instead of vectors as much as I can because I assume that vectors, being more advanced data structures, would take more time to create.

Pointers and references typically incur an extra indirection (possible cache miss too). Therefore, for small data, you should pass it by value. For big data, you should pass it by reference. That's the general suggestion. To do further optimizations, you have to profile your code to see where the bottlenecks are.

vectors have an overhead when created, but not necessarily when accessing elements (via the index operator).
std::array (C++11) is a pure array which have none to little overhead when created, but is still much safer than C arrays.

See this article for more information:
SourceForge.net: Safer arrays in Cpp - cpwiki

Pointers and references typically incur an extra indirection (possible cache miss too). Therefore, for small data, you should pass it by value.

thats exacly the oposite of what thought. thanks, I would pointlessly go the wrong way about this.

Is there the option of reusing existing data structures by resetting and/or updating them instead of deleting and recreating them?

I thought of that, the class will be used in more than one calculation, and in at least one of them I only need a couple of objects and will just reset them when I'm done, but for what is probably the larger part of the work i need a variable number of objects created in sequence (that need data from the previous ones in order to be created).

so for that part I was considering making a vector of the class and push_back. (having 1 object "outside" the vector that gets reused for calculations).
I supose I could have an arbitrarily large array of particles and keep reseting but that kind of defeats the purpose of using C++ (I'm re-coding a Fortran 77 aplication, horrible language, whoever invented "GOTO" should be shot)

vectors have an overhead when created, but not necessarily when accessing elements (via the index operator).

what about extended?

You can use vector. Using the reserve() function, you can reserve a chunk of memory so you won't get reallocations all the time, saving you time. You can use use clear() to get rid of all the data, if you need to start over fresh. It probably won't get rid of the reserved memory, so further push_back's will not cost you so much.

If you store complex objects in the vector, you may consider using emplace_back() (C++11), to further save time.

Functions do not add to size. An object with 1 million functions but no data is just as cheap to construct as an object with no functions and no data.
If that's what you're asking.

The operating system is typically irrelevant. But different architectures can make a difference.
Regardless, 32-bit or 64-bit is usually the domain of the compiler. All you have to do is typically make no size assumptions in order to make it possible to compile it as 32-bit and 64-bit.

Originally Posted by rcgldr

If this program is going to run on PC, and if 64 bit mode is an option, you may want to consider it. Pointers double in size from 4 bytes to 8 bytes, but you get 8 additional registers that help with compiler optimization.

There are tons of plusses and minuses.
E.g. x64 has a better exception handling mechanism. IIRC, It's faster to throw exceptions, but slower to enter a try block.
The performance of an x64 app vs an x86 app might be sometimes better, sometimes worse, and sometimes the same.

In any case, I would stick to a discussion of the language in this instance, and not go into architecture specifics as it is a completely tangential topic.