   using arrays to get best memory alignment and cache use, is it necessary?
  I'm all about performance these days cause I'm developing my first *legal* game engine. I'm no c++ expert but after some research I discovered the importance of the cache and the memory alignment.Basically what I found is that it is recommended to have memory well aligned specially if you need to access them together, for example in a loop.Now, In my project I'm doing my Game Object Manager, and I was thinking to have an array of GameObjects references. meaning I would have the actual memory of my objects one after the other.static const size_t MaxNumberGameObjects = 20;GameObject mGameObjects[MaxNumberGameObjects];But, as I will be implementing a component based design in which game objects will have a list of components (Mesh, RigidBody, Transformation, etc), will I be gaining something with the array at all?Anyway, I have seen some people just using a simple std::map for storing game objects. So what do you guys think?Am I better off using a PURE component model, as I see is the best cache-thought design?   
Quote:Original post by togliaI'm all about performance these days Don't be, especially if your just starting development. Get it working, if you find it's prohibitively slow you can go back and fix it. If you start by worrying about performance at this level you'll never get anything finished.Take note that's not to say you shouldn't be worried about performance at all. Using a linked list when you frequently access elements in the middle would be foolish, but likewise using a vector when you frequently access elements by some key would be equally foolish.   ;  No you won't need to worry about, at least not yet.Yes taking care with cache alignment and arranging your variables into cache coherent structures can help when you're squeezing out the last bits of performance from a piece of hardware.However I'd suggest coding in a way that you find most productive, hopefully following an already established method/paradigm, being there's little point spending your time optimizing code when you have no idea of its running cost to your whole program. You will probably find yourself getting burnt out of this project as well if you've got no real end goal to your optimization. Once you've written your engine/game you can actually set aside goals like reduce physics calculations by 1ms a frame or something, where as as fast as it can be is very undefined.In short, focus on getting the features implemented first and then go back and improve if you need, no one gets it right the first time round.Don't worry about the cache until profiling tells you to :)   ;Quote: is it necessaryNo, not really.Quote:But, as I will be having a list of components per object -Component based design-(Mesh, RigidBody, Transformation, etc), will I be gaining something with the array at all?Possibly. If data can be updated per-component - all meshes, all rigid bodies, all transformations, each in separate for loop, perhaps concurrently, then there are obvious gains to be had.But this design requires components to be designed in such a way that they can be updated in isolation. If a two components need to update each other, or if order of updates is non-deterministic, then no.Quote:I have seen some people just using a simple std::map for storing game objects. There are two aspects - one is storing the component data, the other is cross-referencing it. The references might not be needed for the update step, but depending on design, that might not be practical.Simple example:struct MovementComponent {  vector3 position, target, velocity;  bool moving;  void update(float dt) {    if (!moving) return;    vector3 delta = target - position;    if (len(delta) > 1e-6) { vector3 step = normalize(delta) * velocity * dt; position += step;    } else {  moving = false;  fireEvent(this, ARRIVED);    }  }};This code doesn't converge cleanly for all dt, since it doesn't handle situation when close to destination well, it's just a demonstration.During the update phase, each movement component can be processed completely independently of everything else. It knows all the data it needs and doesn't need entity or any other information.With such design, there are two phases. First, update() is performed on all components. These may generate new events, send messages to other components, create entities. Next there is a "flip()", where all this new data is aggregated into current state.If the system is designed in such a way, then it can be made fairly deterministic and highly concurrent. But it makes intra-component communication difficult and delayed by one update.For complex iteration, direct references and per-entity updates might be simpler.In practice it does not really matter, unless really trying to push the limits of some hardware. On PC, that is mostly moot due to too wide range of hardware.   ;Quote:Don't be, especially if your just starting development. Get it working, if you find it's prohibitively slow you can go back and fix it. If you start by worrying about performance at this level you'll never get anything finished.Well yeah, I would have said that to myself. But actually it took me two years and a couple of horribly programmed games to take the chance and start doing my first little game engine. I want to get my hands dirty this time and use some of the known best/common practices I find.   ;  Why were they horrible? If it's that they were slow you need to look at 'why' they were slow. If it's that they didn't work then performance is the wrong question to be asking.   ;Quote:Original post by togliaNow, In my project I'm doing my Game Object Manager, and I was thinking to have an array of GameObjects references. meaning I would have the actual memory of my objects one after the other.static const size_t MaxNumberGameObjects = 20;GameObject mGameObjects[MaxNumberGameObjects];Use std::vector. It stores everything in a contiguous array so you don't have to! And you don't need to put restrictions on MaxNumberGameObjects since vectors are re-sizable.   ;  Generally when doing something (anything), I like to do it the best possible way I knew how by the time. And, what I have found is that too many things can bash performance hardly. So I just want to be careful.I think I'll keep the array and I'll switch to a Pure Component Model paradigm. Its gaining a lot of popularity and it sure seems to fix a lot of classic inheritance issues.http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/Thanks a lot for your replies.   ;Quote:Original post by Splinter of ChaosQuote:Original post by togliaNow, In my project I'm doing my Game Object Manager, and I was thinking to have an array of GameObjects references. meaning I would have the actual memory of my objects one after the other.static const size_t MaxNumberGameObjects = 20;GameObject mGameObjects[MaxNumberGameObjects];Use std::vector. It stores everything in a contiguous array so you don't have to! And you don't need to put restrictions on MaxNumberGameObjects since vectors are re-sizable.The thing about vectors is that they can move around your memory if you NOT careful, and this can be dangerous if you keep pointers to objects inside, with arrays you have much more control.   ;Quote:Original post by togliaThe thing about vectors is that they can move around your memory if you NOT careful, and this can be dangerous if you keep pointers to objects inside, with arrays you have much more control.What's dangerous is raw pointers! Use smart pointers, allocators and vectors of smart pointers. It's just as performant and much safer and easier to use.   