Games from Within

Historically I think the people that first ran into these issues and started talking about this was gamedevelopers even if it flew under the radar for many others since it was an era of less third party engines and code sharing.

The motivation was partially to solve processing on PS3's, the 7 usable Cell units have small memories of 256kb each so processing had to be moved to a compact/streamable memory format but developers were also concurrently fighting larger cache latencies caused by Entity Component hierarchies that had arisen as a solution to problems with inheritance using dislocated object hierarchies (ie separated linked objects).

Out of this grew the Data Oriented Design paradigm (that's intrinsically built on mechanical sympathy) that suited both Cell like streaming as well as minimizing cache effects for main-memory code where Entity Component Systems were reorganized to use cache efficient array processing instead of linked objects.

https://gamesfromwithin.com/data-oriented-design

Was the outside world oblivious? I'd say so to a large part, CPU's had gotten faster, more cores and memory latencies were masked to a certain degree for other kinds of code!

The Java people even pushed out their biggest mistake just as these effects started to become visible, the erased objects for generics that kind of locked in a design that requires generic list types to have disaggregated storage due to separate objects. In hindsight, this is IMHO the single biggest benefit…

I think optimizing while designing is totally appropriate. In fact you can make some of the most powerful optimizations at the design stage, with almost no additional effort required.

Should you go down a rabbit hole, spending hours optimizing something because you think it might help? No, of course not. To my reading, that is what the warning is about.

But when you're designing a system, especially one that you know needs to be fast, should your design be optimized from the ground up? Yes, in some cases at least. [1]

When I code, I choose to use languages (C++, Go, LuaJIT, JavaScript/Node) that allow me to write code that ends up faster. Some people will cite "premature optimization" based solely on that decision, and they'll write their code in Python, or PHP, or Perl, or Ruby. [2] Since my servers will handle 3000 user interactions per second with no caching, I still contend that this is an appropriate stage for optimization.

I've seen projects fail because the server requirements were too high: 100 concurrent users per Python-based server on a free-to-play game meant that if the app took off, it would be losing money because of the costs of running hundreds of servers. You can't just "optimize" the app if the problem is you need to rewrite it in a completely different language. Computer time in the cloud may seem cheaper than programmer time, but in practice if you pay the programmers up front to do it right, you can cut ongoing operating costs indefinitely. And…

It looks to me that a lot of game programmers are moving away from OO in favour of data-oriented approaches, emphasizing things like structures of arrays (while OOP more or less emphasizes arrays of structures), entity systems (they are becoming increasingly popular, a lot of engines now contain some kind of ES layer) and other similar concepts.

Why? Because OO isn't a perfect fit to modern hardware, is often not the most cache or out-of-order-execution friendly way to organise code and data, doesn't lend itself well to parallelism and isn't suited for stream processors (GPU, PS3's SPEs...)

Actually, the PS3 pretty much forces data to be organised in structures of arrays for the SPEs, as far as I know.

So, yes, as far as I can tell, games do use some form of OO these days, but they also seem to be moving more and more to a data-oriented parallel/streamcache friendly non-OO architecture. I don't think OOP will be forgotten any time soon, of course, as it is still a useful means of modelling games and code, but I do think OO will become increasingly less important.

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

http://gamesfromwithin.com/category/data-oriented-design

http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

http://entity-systems.wikidot.com/start

http://justinliew.com/blog/?p=2890

Kids these days with their allocations and virtual memory. shakes fist

You don't need std::vector if you don't need dynamic memory allocations. Game programming and systems programming is a whole lot different than web or desktop development.

For games, you create a memory budget up front. You decide how much memory sound, textures, models, AI will consume up front and then statically allocate that memory up front.
http://gamesfromwithin.com/start-pre-allocating-and-stop-worrying

You can statically allocate at the start of a game, level, and frame.

From the original article: OpenAL appears to have a limit of 1024 sound buffers, which we bumped into. We could dynamically create and destroy the static buffer mappings without too much trouble, but that is a reasonable number for us to stay under.

It also sounds like Carmack is loading an entire level as a memory mapped file and then doing reads into specific indexes within the file.

Take a look at the source code that id has open sourced. That's the best way to get a feel how this style of development works. I believe RtCW is their last release.
ftp://ftp.idsoftware.com/idstuff/source/
http://github.com/monoid/rtcw-rebirth

IMO, build system for daily work has two very important properties: correctness and speed. Scons seems to get correctness right, but fails to be fast enough (see e.g. http://gamesfromwithin.com/bad-news-for-scons-fans)

Now, there is a third important property, which is clarity. But clarity for a new-comer is less important than a clarity for a person that uses build system daily.

I investigated several alternatives to make for our C++ game framework and settled to Waf. It's quite complex and side-effect of that has caused that we haven't integrated many of our tools to build system, just because doing so requires deep understanding of Waf model. Which I haven't acquired, well, mainly because of laziness.

Thus, clarity can affect both correctness and speed in practical situations of lazy people like myself.

What I like about redo is the simplicity. Based on my initial experiences, it seems that aside multiple output files problem, it doesn't get in to your way.

Well the way you use memory in a game is non deterministic, so "OS having time to free memory" is not a good enough answer. Although you're totally right that the IPhone wasn't designed as a console, so this process is probably good enough for most apps.

Even more interresting than the post in itself (wich is very interresting) is the hack proposed by fishermen21 in the comments - http://gamesfromwithin.com/?p=428#comment-1904 - , wich consist roughly of triggering the low memory handling process at the start of the game while reading a video. Nice workaround if you ask me.

Also , maybe someone around here knows, or my question is stupid, but why isn't a virtual memory mechanism implemented into the iphone OS ?