
Memory and C++ Debugging at Electronic Arts [video] - adamnemecek
https://www.youtube.com/watch?v=8KIvWJUYbDA
======
wsxcde
They say they can't pass parameters to delete so they had to use a macro
instead to be able to pick the right allocator. But why not just store the
pointer to the allocator along with the block and then have operator delete
call the allocator? Is it just because they don't want to store an extra
pointer with each block?

~~~
kayamon
It's kinda an implicit rule in game development that you don't do at runtime
what you can do at compile time.

------
danbolt
Having the privilege of worked nearby Scott Wardle before, I can say he's an
incredibly approachable and helpful guy. It's exciting to see him on the front
page of Hacker News. Go Scott!

------
danjayh
OK. Maybe I just don't understand game development very well, but I don't get
why some of the problems they had in the post-MMU era even existed.

1) Memory Fragmentation - why? This seems like it would only be a problem if
they ran their entire game in the same virtual address space.

2) Subsystem A corrupting Subsystem B's RAM - once again, wouldn't one run the
sim code in one address space, the rendering in another, etc. and have
strategically shared pages for them to transfer data back and forth?

It really seems to me like the idea is 'yeah, we had virtual memory, and it
was great, but we didn't really use it'... Granted, they put guard pages on
some allocations, but that's akin to using supercomputer to solve your family
budget. Lots of power available, but using it in a trivial way.

I acknowledge that there's some cost to a context switch, and that the 2005
generation used PowerPC with its fairly cache-inefficient hashed pagetable
(poor locality), but the benefits of having a hard wall in memory between
major system functions is immeasurable (I'm guessing that on PPC, they just
set up a few Block Address Translation registers and called it 'good enough').

Then again, I come from a safety critical background .. we make aerospace
code, so it's developed using the methods described in the article about 'the
right stuff' that was up a day or two ago. We're really fond of having really
hard walls between every resource we can (memory, CPU time, I/O bandwidth, FS
bandwidth ... you name it) for major system functions. I realize that in game
programming most of those walls aren't practical (due to performance impact)
or necessary, but the memory one is fairly cheap and incredibly helpful.

PS - if you're wondering, we prevent memory leak problems by just disabling
dynamic allocation post-boot, which happens on the ground. Our stack
utilization is also required to be statically analyzable, which means that you
can't do things like recursion. These limitations make the design of some
algorithms extremely painful, but what other software have you ever heard of
that can truthfully claim 0 memory leaks, guaranteed. We also do 100% code
coverage (at the machine language level), 100% decision coverage, static and
dynamic worst-case timing analysis, etc. etc. etc. Look up 'DO-178B' or
'DO-178C' if you're curious about what's done and why safety critical stuff is
insanely expensive. More recently we're throwing in fuzzing for good measure,
but fuzzing doesn't turn up a whole lot in extremely thoroughly tested code
that's been reviewed line-by-line by dozens of engineers (and is subject to
strict design limitations).

~~~
pandaman
Here is all you need to know to understand game development. It's just two
things.

Firstly, on a home console there are just two playable frame rates: 30 fps and
60 fps. This means you can only have frames either less than ~16.6 ms or
~33.3ms long. The next step is 20 fps and if you were even allowed to ship a
game like that it would not make any money so you would likely get fired
anyway.

You will do very unsafe things to stuff as much as possible into a game's
frame because your competition is already doing it and your designers demand
it. There is only one thing you could possibly sacrifice a little bit of
performance for - development time.

Thus there is this second thing: a game has to ship before you run out of
money. The most common production time is about 18-24 months. This is for
millions LOCs of source code and terabytes of source assets (textures, models,
video, sound etc) written, often from scratch, and tested.

How long does it take to ship software for a new plane in your business? I'd
be terrified to even approach a plane that had shipped in 1.5 years, least fly
in it.

~~~
bluecalm
>>Firstly, on a home console there are just two playable frame rates: 30 fps
and 60 fps.

This is probably very basic but I am going to ask anyway: why are 40fps, 45fps
or 47fps not possible?

~~~
MaulingMonkey
Because your monitor is (probably) refreshing at 60hz. Your frames will
display for some integer number of monitor refreshes - at 1 you'll get 60fps,
at 2 you'll get 30fps.

Over a second, it's of course entirely possible to get something in-between,
where some frames are displayed for 1 refresh, and others for 2 refreshes.
Inconsistently waffling between these is going to be more jarring than
sticking to one.

Recently, you have things like nVidia's... gsync? Which make the monitor
refresh rate variable with compatible monitors, to match the game framerate,
making 45fps entirely possible, and reducing the jarring from varying frame
lengths. But this recent, rare, and likely PC and/or GPU vendor specific
still.

------
melling
I imagine game developers are the few people left using C++. Does this come
down to not being able to get around pauses in garbage collection?

I wrote a little C++ in iOS a few years ago when I thought I might try to
share some code with Android. Unfortunately, Objective C++ was slow to
compile. I think the biggest problem with C++ is that it's simply harder to
get correct code:

[http://www.gamasutra.com/view/news/128836/InDepth_Static_Cod...](http://www.gamasutra.com/view/news/128836/InDepth_Static_Code_Analysis.php)

[Update]

Sure, there's a lot of code that was started 15-20 years ago that was written
in C++ because it was the best thing at the time. Java's JIT has greatly
improved. I'm sure C# is also great. Large apps like Hadoop are written in
Java. IBM's Watson is mostly Java.

[http://www.drdobbs.com/jvm/ibms-watson-written-mostly-in-
jav...](http://www.drdobbs.com/jvm/ibms-watson-written-mostly-in-
java/229300226)

Why does C++ offer advantages over C# on Windows, for instance? In 2015,
starting from scratch, where is C++ needed?

Please consider that I was using C++ when it was cfront. I seem to be getting
a lot of "how naive" from people who've probably never used C++. Yes, there
are dozens of desktop apps in C++, especially legacy, but there are millions
of apps, mobiles apps, and web apps that are in other languages.

~~~
davidgrenier
Too bad nobody directly addressed your question as to whether it had anything
to do with pauses which would be unbearable on the gamer's experience.

Perhaps the question is still open whether properly managing allocation, using
object pools as well as other strategies would enable writing triple A games
with a managed language.

Or perhaps all we need is a GC race (à la JS engine race we've seen in the
major browser) which Google might very well be starting with the recent
efforts on the Go garbage collector.

~~~
kayamon
It's not that you couldn't write a triple A game with a managed language.

It's that you can _quite easily_ write a triple A game _without_ using a
managed language.

For games, managing memory is not a big problem. For other kinds of apps, it
can be. In some apps the lifetime of an object is not well defined. But in
games, it tends to be very well defined.

If you want a good explanation of the problems game developers face when
trying to use GC, go read Rich Geldreich's post on it
([http://richg42.blogspot.com/2015/05/lessons-learned-while-
fi...](http://richg42.blogspot.com/2015/05/lessons-learned-while-fixing-
memory.html)).

~~~
Zardoz84
There some AA or AAA games using languages that not are C/C++ . Severence:
Blade of Darkness (Aka Blade: The edge of darkness), have a lot of code on
pure Python. And it's well know that Naughty Dog use a variant of Lisp on his
games.

~~~
kayamon
I'm sure there are - that's not what I said.

Also, Naughty Dog's games do _not_ use Lisp, they use a custom language that
_looks_ a little like Lisp, but has no garbage collector.

~~~
z3phyr
Naughty dog used to use Game Oriented Assembly Lisp (GOAL), which was very
scheme like. They dropped it for C++. Although they still use a Racket dialect
for some gameplay scripting.

