C Vs. C++

[GeminiDomino]

Thanks to going back to school, I've picked up C++ and I'll admit, I'm a much better OO programmer than I was in procedural C.

I'm looking to start coding for the 2X (mostly so I can justify the cost as the emu projects die) but I'm a bit concerned that there might be a performance hit on the already overworked CPU and especially the RAM. Can anyone offer personal anecdotes, benchmarks, etc... as to the differences, speed- and size-wise, between the two languages/styles in the end?

 

[Squidge]

depends what parts of the languages you use. If you just use simple classes/templates/etc to keep your code looking nice, there's not much between them, but if you start using a lot of virtual constructors and the like (ie, stuff that requires a lot of management by the runtime library), then expect your code speed to go downhill quite rapidly.

I always prefer to use C on a an embedded platform such as the gp32/gp2x/etc which has limited ram and processor speed, and C++ on a desktop PC where ram and cpu speed is usually plentiful.

 

[GeminiDomino]

depends what parts of the languages you use. If you just use simple classes/templates/etc to keep your code looking nice, there's not much between them, but if you start using a lot of virtual constructors and the like (ie, stuff that requires a lot of management by the runtime library), then expect your code speed to go downhill quite rapidly.

I always prefer to use C on a an embedded platform such as the gp32/gp2x/etc which has limited ram and processor speed, and C++ on a desktop PC where ram and cpu speed is usually plentiful.

Thanks, Squidge. I also heard that I should avoid the STL for the same reasons. So if I avoid overusing polymorphism (which shouldn't be a problem...) I should be OK, since a class is just a struct that defaults to private status, right?

I just like using classes so that I can make as much as possible a self-contained proper type. Makes my logic much cleaner

 

[Parkydr]

I generally use C++ including STL, and haven't had any problems with performance/memory, it just depends what you want to do. In most cases C++ is fine.

 

[GP2X_Coder]

Thanks to going back to school, I've picked up C++ and I'll admit, I'm a much better OO programmer than I was in procedural C.

I'm looking to start coding for the 2X (mostly so I can justify the cost as the emu projects die) but I'm a bit concerned that there might be a performance hit on the already overworked CPU and especially the RAM. Can anyone offer personal anecdotes, benchmarks, etc... as to the differences, speed- and size-wise, between the two languages/styles in the end?

I use c++ for everything on the gp2x and with proper optimizing I find it difficult to go below 70fps most of if not all of my games run at 80+fps when finished my last game Bare Fist Fighters has rather large sprite and it runs in the 90-110fps range. I still wonder about people that are getting only 30-40fps and what they are doing wrong?. I want to make a site that is for gp2x optimizing only to help everyone out but I am so overwhelmed with work at the moment I don't have much time to do anything. Anyway getting side tracked <_< you should have no problem what so ever using c++ anyway you like on the gp2x.

 

[Squidge]

Thanks, Squidge. I also heard that I should avoid the STL for the same reasons. So if I avoid overusing polymorphism (which shouldn't be a problem...) I should be OK, since a class is just a struct that defaults to private status, right?

I just like using classes so that I can make as much as possible a self-contained proper type. Makes my logic much cleaner

Yep, You can certainly use the STL in cases where speed doesn't really matter (Ie, where there is little going on, such as menu screens, initialisation, loading, saving, highscores, etc) but I wouldn't use it in your main game loop where every millisecond counts. Of course if your games runs at stupidly high framerates because your hardly doing anything, then go ahead, but if you find out later after adding more effects or whatever that it drops through the floor, at least you know where to optimize

 

[TKF15H]

About polymorphism... has anybody checked to see if it actually does impact speed on the ARM? I know that on an X86 it is slower than a static JMP, but on the ARM processor, GCC uses registers as jump targets even if it's a static far call (dunno about the static near calls). So they should be the same speed, right?

 

[Alex.]

my last game Bare Fist Fighters has rather large sprite and it runs in the 90-110fps range. I still wonder about people that are getting only 30-40fps and what they are doing wrong?

When I start a project nice and fresh, it runs at a swell 111-112 FPS. Then the drops come:

- Background music: it takes as much as 17 FPS away, depending on the sound file format (I'm talking SDL_mixer, with stereo 11025 rate).

- The blitter is overworked. From 111 FPS it drops to 55FPS in a jiffy, the difference being very few sprites.

- Using a lot of graphics primitives (SDL_gfxPrimitives)

Did anyone else encounter these things?

- Alex

 

[Thecko]

If you're concerned about speed disadvantages of linking against libstdc++ then there are ways around it.

As you said - you can use structs and inline functions specifically coded to handle certain jobs.

Remember to pass your struct members in by reference specifically (ie a mem address pointer to your struct) to make sure you're minimizing the hit on memory usage (I can't remember off-hand whether C defaults to passing parameters by value or by reference).

 

[gmiller1018]

If you're concerned about speed disadvantages of linking against libstdc++ then there are ways around it.

As you said - you can use structs and inline functions specifically coded to handle certain jobs.

Remember to pass your struct members in by reference specifically (ie a mem address pointer to your struct) to make sure you're minimizing the hit on memory usage (I can't remember off-hand whether C defaults to passing parameters by value or by reference).

"value" so if you put a structure in a parameter list the whole thing get's pushed on the stack. C++ does the same so you should make sure to use references in C++ and address of (&my_struct) in C to pass a structure.

 

[gfoot]

About polymorphism... has anybody checked to see if it actually does impact speed on the ARM? I know that on an X86 it is slower than a static JMP, but on the ARM processor, GCC uses registers as jump targets even if it's a static far call (dunno about the static near calls). So they should be the same speed, right?

Interesting thought. I found it kind of hard to test distant static jumps. Using a big fat asm(".zero 10000000") statement to stretch some function calls, gcc 4.0.2 still uses a simple bl instruction to perform a static function call, with a 10Mb gap. Upping the gap to 100Mb caused a slew of linker errors, so how it deals with long jumps is inconclusive - maybe you need compiler switches to enable the behaviour or something.

I'd say with the amount of RAM available on the GP2X, pretty much all your static calls are going to be within range, so the virtual method call overhead is still the same issue as usual.

I looked at a virtual method call, too, and it looks much as you'd expect - about the same sequence of events as on x86, say, and slower than a direct call for the same reasons (cache misses, dependent instructions, indirect branching).

 

[Squidge]

a B/BL is good enough for 32MB I believe, so most if not all gp2x programs. Anything beyond that will require two statements - "MOV LR, PC" (if a return is required) followed by either "MOV PC, <reg>" or "LDR PC, <loc>".

I don't think it's just the jump that takes all the time, but I've not looked at the assembler listing of any such program, so can't really comment further.