Jump to content

  • Log In with Google      Sign In   
  • Create Account

akesterson

Member Since 14 Oct 2012
Offline Last Active Jul 11 2014 04:55 PM

Posts I've Made

In Topic: When to start with C++?

10 March 2013 - 06:34 PM

Why wouldn't you use full optimisation for a release build? Of course you're going to use -O2... and looking at performance in a debug build is just meaningless... debug builds are for stepping through code and debugging it...

 

That's not a debug build, that's just unoptimized. Debug builds include stabs, extra nametable info, etc, none of which the -O0 builds include. -O0 just means that there is no optimization performed by the compiler - how your code is written, is how it will run.

 

Yes, you will make a production build at -O2 or potentially even higher, and when you do that, you'll get near-C levels of performance. But that's not the point. The point is that the containers perform terribly until the compiler gets its hands on them and optimizes them; why? There's no obvious reason for it, not when C and glib are smoking it by orders of magnitude. RTTI and dynamic dispatch can't account for all of the slowness there - the C++ STL containers just aren't written for performance from the get-go.

 

Just realized we're jacking OP's thread, can make a separate thread re: STL performance if we want to keep talking about this.


In Topic: When to start with C++?

10 March 2013 - 06:19 PM

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Which containers and on what platform? Do you have data to support this conclusion available to show us?

 

Google "C++ STL performance" and you'll be inundated with people complaining about the performance, with no indication that it is relative to any one compiler or implementation. std::map and std::vector are particularly troublesome offenders. Compared to their counterparts in Boost, or their dynamic contemporaries in languages like Python, their performance is garbage until you start cranking up the compiler optimizations (which make the code arguably more difficult to debug.)

 

I have some example numbers on a (very narrow set of use cases) in a thing I've been putting together to illustrate these issues, actually. 

 

https://github.com/akesterson/perftests/tree/master/countstrings

https://github.com/akesterson/perftests/tree/master/countints

 

Those two test cases illustrate C (with glib & hash maps) vs C++ (std::map and std::unordered_map) vs Python vs JavaScript vs Bash, comparing their relative execution speed to count the occurence of an item in a list of items (strings and ints), to illustrate the speed of each implementation's containers in setting, looking up, and checking for the existence of keys.

 

You CAN get C++ STL containers to perform admirably (see the -O2 settings on the documentation), but out of the box, the containers perform incredibly badly.


In Topic: When to start with C++?

10 March 2013 - 08:44 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.


Talking about premature optimisation and then saying to avoid the standard library for performance reasons is a massive self-contradiction.

 

Actually, no, it goes to prove the point. Many times, when deciding to optimize early based off of minor observations, without really completing the solution, you just muck it up. In this case, OP is asking to switch to C++ because (essentially) "that's what everyone uses"; having a java background, OP would expect the C++ STL containers to confer that same sort of naive "all native code is fast" performance benefit, when in actuality, they're the fastest way to murder C++ code.

 

Write first, optimize later. OP's java will quite likely be faster than their C++, since they already know their Java, and the best patterns/weaknesses in the language. If they write their Java and finds that it is, in fact, too slow (or nobody wants to run Java), then they can look to a new language.

 

Unless they really honestly just WANT to learn a new language, just for the sake of learning it, which is an entirely different conversation.


In Topic: Tiled games

10 March 2013 - 07:56 AM

@Endurion, that solution is cool, the problem with it is that all the bounds checking (e.g. only check tiles X1,Y1-X2,Y2) is done at collision time (meaning it runs every single time). It is arguably more efficient to treat your colliding map tiles (not all map tiles collide with the player) just like enemies/bullets/etc, and have them use the same collision quadtree, which is only updated when something moves.

 

But +1 for static arrays, an often overlooked performance winner.


In Topic: When to start with C++?

10 March 2013 - 07:01 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

 

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.


PARTNERS