Jump to content
  • Advertisement
Sign in to follow this  
WillPash

C Arrays Vs Boost::Arrays

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all Just a short query on if anybody has any experience of using Boost::array for game development and I wonder does it offers any performance improvements over the traditional c array. I have heard std::vector and std::list does hit performance even though it is meant to be dynamic, and clearly has it's disadvantages. As Boost::array is static like a traditional c array and it is set up as a templated class, what advantages and disadvantages does it have for game development and performance..... If I have got anything wrong, forgive me as ive only just started researching on it and its usages... Regards

Share this post


Link to post
Share on other sites
Advertisement
There is no simple answer. The details depend a lot on your environment.

If you are on a small console or handheld, the static or auto arrays and template-based fixed-length arrays have one key benefit: they cannot fragment memory.

If you are on a system where fragmentation isn't a concern, such as a modern PC, then you really ought to learn how to use the dynamic versions properly. Used correctly they incur no significant overhead.

Share this post


Link to post
Share on other sites
Quote:
Original post by WillPash
I have heard std::vector and std::list does hit performance even though it is meant to be dynamic, and clearly has it's disadvantages.


Yes and no.

Quote:
Original post by WillPash
As Boost::array is static like a traditional c array and it is set up as a templated class, what advantages and disadvantages does it have for game development and performance.....

If I have got anything wrong, forgive me as ive only just started researching on it and its usages...

Regards


The whole point of boost::array can be summarized by one line from the online reference: [boost::array] is safer and has no worse performance than ordinary arrays. For example, they add additional safety by supplying accessors that can throw exceptions when the index you're accessing is out of range.

Share this post


Link to post
Share on other sites
Personally i prefer boost::array over a plain C array because it has the same performance (it is just a very simple wrapper), but is a bit safer to use (it won't decay to a pointer for example). On the static vs dynamic question, i agree with frob. The overhead of using a vector over a static array on a Desktop Computer will be negligible except for special cases (and it will be easy to recognize those cases when you encounter them). There are even scenarios where you could HURT performance by using a static array class too much. For example, if you write a large template function which takes as a template parameter the size of the static array it takes as an argument, you could end up generating too many instances of this function, and consequently get larger code size and poorer cache behavior due to instruction cache misses.

[Edited by - D_Tr on June 9, 2008 2:32:23 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by D_Tr
On the static vs dynamic question, i agree to frob. The overhead of using a vector over a static array on a Desktop Computer will be ridiculous except for special cases (and it will be easy to recognize those cases when you encounter them).


There is somewhat of a fallacy in this statement. There is no "over-head" in using a vector as compared to an array. You simply have to "pay for" the extra features it provides.

If you create an std::vector of a particular size and never cause the vector to grow in size by exceeding its load factor, the compiler produces code 100% equivalent to a raw array.

The performance "penalties" you speak of involve things like inserting into the middle of the vector, where every element beyond the point of insertion needs to be copied. You can't use points like these to say a vector is "slower" than an array because arrays can't even perform operations like these in the first place.

You should remember: a vector is an array.

Share this post


Link to post
Share on other sites
Quote:
Original post by WillPash
Just a short query on if anybody has any experience of using Boost::array for game development and I wonder does it offers any performance improvements over the traditional c array. I have heard std::vector and std::list does hit performance even though it is meant to be dynamic, and clearly has it's disadvantages.

I once heard that a big fat guy in red clothes comes down your chimney on Christmas Eve.

You can't believe everything you hear.

As always, the best way to understand the advantages/disadvantages of any piece of code, is to understand it. A statically-allocated array of any kind has one small advantage. You know where the data is allocated. You don't need to first read a pointer to figure out where the array starts.

With a dynamically-allocated array, of any kind, you only actually have a pointer, which tells you where the actual array is. Other than that, the only difference is if the datatypes enforce some kind of extra semantics, such as bounds-checking.


int arr1[200]; // Statically allocated
boost::array<int, 200> arr2; // Statically allocated

int* arr3 = new int[200]; // Dynamically allocated
std::vector<int> arr(200); // Dynamically allocated


Now, none of these actually promise to do bounds-checeking. The vector *might* do so (Microsoft's implementation does so by default, which incurs a (usually small) overhead. But that can be disabled, and none of the other do bounds-checking)

So what exactly would cause performance to vary for any of these?

Indexing into a boost::array or std::vector obviously goes through an overloaded operator[], which seems a bit less efficient than directly indexing into an array. Except that's not the case. Any half decent C++ compiler is fully capable of inlining this function, which means that in practice, there is no difference performance-wise.

In any case, until performance becomes a problem, you should go for the safest, least error-prone approach. Which means boost::array or std::vector or other such containers. And pretty much never raw C arrays.

Share this post


Link to post
Share on other sites
@fpsgamer:
Yes, i absolutely agree with you about the extra features. When i said "negligible overhead", i meant those 12 extra bytes per array to store size, capacity and pointer and then possibly some more bytes generated by the memory allocator for each dynamically allocated chunk of memory. There are cases, however, when these few bytes (x2 in 64-bit machines), might be a pain when you have to deal with many-many very small arrays in performance-critical situations.

[Edited by - D_Tr on June 9, 2008 2:45:49 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
The vector *might* do so (Microsoft's implementation does so by default, which incurs a (usually small) overhead. But that can be disabled, and none of the other do bounds-checking)



std::vector<int> v;
...
int foo = v.at(3);


The above accessor checks bounds and can throws a bounds exception. As a result it will be (nanoseconds) slower -- but that is the price you pay for safety.


std::vector<int> v;
...
int foo = v[3];


The above accessor doesn't check bounds (according to the spec). As spoonbeder said, good compilers can produce code that is equivalent to indexing an array.

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer

The above accessor doesn't check bounds (according to the spec). As spoonbeder said, good compilers can produce code that is equivalent to indexing an array.


MVS implementation uses checked iterators, which result in overhead unless specifically disabled. Use #define _SECURE_SCL 0 to disable them.

[Edited by - Antheus on June 9, 2008 11:11:05 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by D_Tr
@fpsgamer:
When i said "ridiculous overhead", i meant those 12 extra bytes per array to store size, capacity and pointer and then possibly some more bytes generated by the memory allocator for each dynamically allocated chunk of memory.


12 bytes is hardly "ridiculous" on modern computers. Even if memory were a problem, trying to shave off 12 bytes at a time is micro-optimizing, and wrong.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!