Jump to content
  • Advertisement
Sign in to follow this  
someboddy

Using malloc and memcopy in C++

This topic is 3570 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

Advertisement
For POD types, it has the same semantics as in C.

But there is no real reason to use malloc for PODs. There's also std::copy portable version of memcpy (which usually delegates to memcpy).

Share this post


Link to post
Share on other sites
It's *OK-ish* with POD (http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7) but there are some gotchas. You should use "new" instead of malloc. std::copy is also a safer alternative to memcpy in many cases.

This is a general reply to your general question. Things could get more specific though.

Share this post


Link to post
Share on other sites
Well, I have a 2D vector class, and a polygon class that has an array of that vector class. The polygon class gets copied around alot during the calculations, so I figured that to speed things up, I can used memcopy to copy the vector array instead of looping through it. My vector class is a class, but there is nothing stopping me from making it a struct. Also, the only critique in the POD definition that my vector class doesn't mach is having a constructor, but I only use the constructor to set the x and y values, so I don't think it should be such a problem...

Share this post


Link to post
Share on other sites
It sounds like you think using memcpy and malloc is going to be faster than new and std::copy. But for equivalent correct uses of either the performance will also be equivalent. It's not worth stripping functionality from your class just so you can safely memcpy and malloc instances of it.

Have you actually determined that copying the array of vectors during the copy operation for your polygon is a bottleneck? Have you considered alternative algorithmic solutions to avoid the copy overhead?

Share this post


Link to post
Share on other sites
If you have a lot of copying, make a reasonable effort to reduce it as much as possible. After you have done that, make sure your data is properly aligned and properly sized for all optimizations malloc/std::copy provide (mainly, using SIMD instructions) For larege arrays, this should definitely be faster than looping through manually.

Using malloc should not give you a performance boost over new.

Having a constructor yet being ok for you array to be allocated with malloc si a proff of a conceptual problem. Either you don't need a constructor and you will handle initializing stuff yourself, or you do need a constructor and you are going to have some problems because it won't be called.

Last point, struct differ from class as all members are public by default in a struct. Nothing else. Correct me if I'm wrong but you seem to think otherwise.

Share this post


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

The polygon class gets copied around alot during the calculations, so I figured that to speed things up, I can used memcopy to copy the vector array instead of looping through it.


mempcy will be probably faster by a few fractions.

Reducing number of copies however will be faster by a factor.

If you're copying between states, then consider changing your algorithms so they operate on two buffers. So instead of copying the array, then modifying values in place, perform the operation from old array into new.

Share this post


Link to post
Share on other sites
std::vector is smart enough to detect when you use a pod type and then internally use std::copy, which in turns uses memcpy.

The difference is that your code will look much cleaner than if you use malloc/memcpy manually.

Share this post


Link to post
Share on other sites
std::vector probably always uses std::copy internally, which if the type has "trivial assignment" and the iterators are random access might be implemented in terms of memmove (at least in MinGW). However do the compilers realize that the assignment is indeed trivial for user-defined types?

Not saying that reducing the copying itself rather than optimizing the method of copying is a better answer, I don't have infinite trust in compilers and STL implementations. For example, recently I discovered that std::iter_swap in MinGW 3.4.5 is not implemented in terms of swap, meaning that none of the std algorithms in this implementation take advantage of overloaded efficient swap methods (e.g for types such as std::string).

Share this post


Link to post
Share on other sites
I did check the current gcc implementation. It uses the tr1 is_pod type trait to determine if the type is a pod, and if it is uses __uninitialized_copy, which in turns I seem to recall was using std::copy but I may have had that bit wrong. The code's a bit difficult to follow. But it did end up with a plain memory copy.

Yeah, some older implementations of the stl might be subpar, but it's hardly something to worry about when proper implementations are as easily available.

I'd rather have my code run sub-optimally on some compilers than uglify it with premature optimizations that will be irrelevant in a few years when people stop using old compilers.

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!