Why is low level programming used to create great games?

Started by
42 comments, last by Hodgman 10 years, 7 months ago

Boy, it would have to be SOME game if you need to use C++ for performance reasons.

Advertisement

Boy, it would have to be SOME game if you need to use C++ for performance reasons.

Any game on current-gen consoles tongue.png

On the last few that I worked on, the game code was mainly written in Lua, but periodically, the slowest parts would be identified and ported over to C++ in order to keep the game running at 30Hz. Keep in mind that (ignoring the SPU's), the PS3 isn't a multi-core system, and the main CPU is extremely simple compared to a desktop x86 CPU. The 360 has essentially the same handicapped CPU, but a triple-core version (but no SPUs).

There's workloads that a modern i5, i7, etc will laugh at, but which would completely bog down a current gen console...


If you're going to use C++ for performance reasons you have to be prepared to write compiler specific code, otherwise you won't gain much.

There's a lot of performance-centric things that C++ allows you to do, without leaving the realm of standard/portable code.

Most of the optimization work I've done in recent years has been on improving memory access patterns -- how things are laid out, where they're allocated, and when they're used. This is because CPUs keep getting faster, but in relative terms, memory is getting slower and slower. C/C++ are great languages for this work. C# lets you do it somewhat, but it's incredibly un-idiomatic.

In C++03, you needed non-standard code to do some alignment tweaking, but not any more in C++11. The only other non-standard tools are the ones to mess with with vtable implementations, (but I'd never recommend doing that anyway wacko.png) and to affect the order of code/data within the final EXE (which is in most cases a silly microoptimization, like ASM programming tongue.png).

restrict still isn't available in C++11 (it is available in C though) and is pretty useful for telling the compiler when memory access is guaranteed to not be aliased. it can have a quite noticable effect if used appropriatly (atleast with g++, other compilers might do a better job at figuring it out for themselves), SIMD is also pretty much required in many situations these days (Allthough i can't think of any language that actually support SIMD directly).

[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

Allthough i can't think of any language that actually support SIMD directly

I'm using ispc for that ;)
Modern C++ compilers also do a soft-of half decent job of it if you use appropriately aligned data types.

Regarding restrict, there's a lot you can do just with writing sensible code that helps the compiler do the same thing, and every engine I've worked on has simply added their own restrict macro, which is defined appropriately for every compiler (e.g. #define RESTRICT __restrict). The nice thing there is that if theoretically there's a modern compiler that doesn't have it's own 'restrict' extension, you can simply define it as an empty token, and you code still works (it just doesn't get the optimization benefits).

i.e. your code is still portable, just the optimizations might disappear.

This topic is closed to new replies.

Advertisement