• 12
• 12
• 9
• 10
• 13

Which is faster?

This topic is 2567 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

which would be faster, having a bool in the Draw() to turn off/on drawing an object or a list of objects and you just remove that object say from a vector and fill the vector with the pointer when needed?

Share on other sites
Without much detail given, I would say the bool option would typically be faster.

Test both.

Share on other sites
Well I am not sure what else to say other than I would do something like this

 std::vector<Object*> objs, objsOriginal; for(int i = 0; i < 1000; ++i) objs.push_back(new Object()); objsOriginal = objs; void Draw(void) { for(size_t i = 0; i < objs.size(); ++i) objs->Draw(); } //in Object Class void Draw(void) { if(draw) { } } //vs. in the Logic() or somewhere //remove objects to be drawn objs.erase(); 

this isn't tested but just something to show what I was thinking about....

Share on other sites
Removing it from the list seems much more efficient. You remove the "if(draw)" branch for each iteration.

Share on other sites
How consuming is it to to test a boolean value? It gotta be the fastest thing a computer can calculate. But having a list of all object that will get drawn maybe is faster, but it gotta be without margin.

Share on other sites
While testing a bool might be fast just focusing on that ignores the other factors namely transfer from memory.

To test that bool you have to;
• jump into the function (bonus cost if its a virtual)
• load the data for the object at (and around due to CPUs loading cache lines at once) the 'bool' you want to test
• test it
• optionally jump back out again or go on to do the workAnd you would do this every frame.

By constrast removing a pointer is only going to be done on the frame the object is removed saving you the overhead of a test each frame and removing the above, useless, per frame work from every 'object' which is drawn.

Basically, with the 'render list' memory you are taking advantage of temporal coherancy of a given scene to reduce your workload to the point where you need to do it, with the 'test bool' method you are taking advantage of an out-of-order CPU with huge caches to cover up your poor design

Share on other sites

How consuming is it to to test a boolean value? It gotta be the fastest thing a computer can calculate. But having a list of all object that will get drawn maybe is faster, but it gotta be without margin.
Doing the actual test is fast, but after doing the test you've got to issue a conditional branch.
On PowerPC CPUs (xbox/ps3), conditional branches are likely to cause branch mispredictions, which are ungodly slow. Also, jumping into a function and jumping back out again too quickly can be horrendously slow as well, as the function prologue/epilogue both touch the same part of the stack in quick succession causing a LHS (load-hit-store stall).

x86 CPUs tend to have decent branch prediction hardware, and don't suffer from LHS like PPC does... but branching should still be kept in mind as an expensive operation, not something that's really fast.

Share on other sites
Thanks all for the input. I figured that removing just a pointer from a list would be faster than testing, but wasn't going to jump to any conclusions without some advice.

Also, think of that list being called on logic for each object also, that would also be reduced per frame.... Adds up.

Share on other sites

While testing a bool might be fast just focusing on that ignores the other factors namely transfer from memory.

To test that bool you have to;
• jump into the function (bonus cost if its a virtual)
• load the data for the object at (and around due to CPUs loading cache lines at once) the 'bool' you want to test
• test it
• optionally jump back out again or go on to do the workAnd you would do this every frame.

And if some draw flags are set and some aren't, the branch predictor won't be able to predict the branch either, causing pipeline stalls. If the list insertion/removal code is lightweight, it may be worth eliminating branches in the inner loop.