Sign in to follow this  
Clairvoire

Struct vs. Typedef'd array

Recommended Posts

My thread titles still need work, they do... Anyway, I'm making a simulation that uses particles, lots of them, and have decided for each particle to be 32 bits wide, and have 4 properties, 8 bits wide each. The problem though is that I've been bouncing between two, or well, three different ways of representing particles. The first way, being raised on OOP, was to make a struct: struct Particle{ Uint8 phenotype; Uint8 decay; Uint8 strength; Uint8 data; }; Which is fine and well, but I'd like to reference each member of a particle using, say, a number, 0 - 3, like a regular array. Also, I wouldn't need to reference each member every simulation step. For instance, only a few 'phenotype's need their 'data' members interpreted. So, anyway, my question: Should I use the struct I have above, and use a switch/case to get each member based on a subscript number, perhaps by overloading the [] thingy? Or would something like this be more fitting: Typedef Uint8 Particle[4]; or even Typedef Uint32 Particle; // ~hazzah bitwise One's more readable, certainly, but I'm more concerned with performance than readability. Which should I go with?

Share this post


Link to post
Share on other sites
How many is "lots of them"? What platform are you on?

On a modern PC, you aren't going to see any significant performance difference between any of those representations until you get into many thousands of particles being adjusted every frame. You'll hit some cache memory effects when it gets big, but even that isn't going to be huge compared to all the other more significant design choices.


Personally I'd just go with an array of structures and be done with it. It's easiest to read. Let the compiler figure out how to optimize it. That way you can focus on your *real* performance issues.

Now if you were on a smaller platform, such as a handheld of some sort, and if you knew that these particles would never be changed, I would consider the bitwise operations.

In either case, I wouldn't bother with the array of Uint8[4] items, because it is much less readable and might (depending on how smart your optimizer is) require an extra few instructions to access individual details.

Share this post


Link to post
Share on other sites
There'd be around several thousand, I suppose. They are used as the primary method of sending information around, like sunlight, sound, smell, energy, heat, etc. (In that sense, 'Particle' is a pretty poor name for the struct. I should probably rename it when I can think of a better term, haha)

Basically, I'd like to be able to unload thousands and thousands into a system haphazardly, and have that make up for the limited amount of data they convey. It's a pretty inefficient system, but it's one that I want to simulate~ Any possible boosts I can get to make up for that inefficiency that doesn't hinder the simulation itself would be a huge help.

Share this post


Link to post
Share on other sites
A struct and a class are functionally equivalent. In a struct all members are by default public, where in a class they are private. So you can overload the [] (array) operator if that's what you'd like to do.

If you wanted to overload operator[] you might go with something along these lines


struct Particle
{
Uint8 values[4]

enum ValueType
{
PHENOTYPE,
DECAY,
STRENGTH,
DATA
} ;

Uint8& operator[] (std::size_t i)
{
assert(i > DATA);

return values[i];
}

const Uint8& operator[] (std::size_t i) const
{
assert(i > DATA);

return values[i];
}

} ;




I don't personally think thats what you're doing is a well designed OOP construct but that is how you would do it.

Other than that I don't want to make a comment on performance until I see what exactly you're doing with said particles. There are a lot of issues that are more related to the graphics card, assuming you're drawing said particles, that would affect your performance more than your chosen representation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this