Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory and C++ Debugging at Electronic Arts [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Memory and C++ Debugging at Electronic Arts [video]

#41

Post by inDigiNeous »

melling wrote: post #2

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/128…

I can answer only for my own account, but for starting a new project in late 2013 december, and now been working for it the past two years, related to custom geometry generated in VR, C++ was the only viable crossplatform option.

With C++ (using the C++11 standard) I can assure pretty sure that the code compiles on Mac, Linux, Windows, Android, iOS and pretty much every platform.

With the VR -platform we also need all the performance we can get, because target FPS is 90 on a stereo rendering sized area.

Also, library support, existing code to use and so on all win here.

Definitely C++ is not the most nice language to get into, Objective-C for example is much nicer IMO. But the more you use C++, the more nicer it gets as you learn the ropes more and more. It's a very complex language, but knowing it pays off in the long run, and the modern C++11 and C++14 are a completely different beast than the previous implementations in terms of ease of usage and code syntax niceness.

So, crossplatform is a big thing. If I would write it in C#, it would be tied to either Microsofts C# or the Mono implementation. If I would have chosen Obj-C, it would be pretty much Mac and iOS only.

When you need performance + crossplatform, C++ just wins.

Re: Memory and C++ Debugging at Electronic Arts [video]

#42

Post by plexchat »

pcwalton wrote: post #23
plexchat wrote: post #3

Earlier quoted context omitted.

At PlexChat[1], we intend on using C++ to write a lot of our infrastructure (where it makes sense, that is). The language has advanced significantly in the last decade and writing idiomatically correct, and safe code, is much easier than it used to be.[2] Garbage collection is certainly a part of it, but really, it's about programming with a deterministic runtime. Controlling memory budgets and doing things described…

> Other languages optimize understandability of the programming semantics (what is this algorithm doing) but do very little to aid in expressing runtime semantics (how will this algorithm execute on the machine). I think this is painting other languages that aren't C++ with too wide a brush. There are many non-C++ languages that make it "easy" to control the low-level generated code (though I question really how easy…

Other languages, not all other languages ^^. Yes of course there are several languages that map more directly to one's mental model of how code is executed. Rust (which you're working on) is an one such exception. Optimizations are certainly aggressive but the micro-optimizations are usually either well known (like NRVO, loop unrolling, function inlining), or not important relative to more costly operations that are occurring (allocations of heap memory, fetching from the heap, executing a system call, acquiring a mutex, etc).

Re: Memory and C++ Debugging at Electronic Arts [video]

#43

Post by corysama »

danjayh wrote: post #26

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,…

1) Virtual memory only helps you to the granularity of a page. So, 4k at minimum. Meanwhile, a PS3 has exactly 256 megs of memory available to the CPU and we are highly motivated to use every last goddamned byte of it because if we don't, our competitors will. Meanwhile 2, the vast majority of allocations are under 512 bytes. In practice, even that subset is mostly 2) A lot could be done better here. 4 gigs is not a ton of address space to protect different systems from each other. But, if you assume no system is going to ever need more that 64 megs, then you could divide memory into 64 spaces of 64 megs each and never have to reuse memory between different systems. I haven't heard of anyone doing this. You'll still get corruption from garbage data ending up in pointers. But, virtual memory segregation would cut out a large class of problems.

Static allocation post-boot is not an option in games. You can be very strict and structured, but the needs of different situations are still too varied. Sometimes you need 90% UI, sometimes you need 10 gameplay regions, sometimes you need 100% devoted to a single, small room for a boss fight.

Similar to fuzzing, I've worked on games that user controller-monkeys. An AI "player" was set up to artificially progress through the game while spamming the system with random actions. We would set all of our machines to monkey-mode each night before going home. In the morning, we would have a fresh set of obscure crashes to investigate.

Re: Memory and C++ Debugging at Electronic Arts [video]

#44

Post by plexchat »

davidgrenier wrote: post #11
melling wrote: post #2

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/128…

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)…

The speed of the GC isn't the issue (although it certainly can be). The non-determinism is. It's hard to control when a GC should happen, and when it happens at a bad time, the ramifications are perceived as an awful user-experience.

Re: Memory and C++ Debugging at Electronic Arts [video]

#45

Post by kayamon »

Zardoz84 wrote: post #40
kayamon wrote: post #13

Earlier quoted context omitted.

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 f…

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.

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.

Re: Memory and C++ Debugging at Electronic Arts [video]

#46

Post by MaulingMonkey »

danjayh wrote: post #32
panic wrote: post #27

Earlier quoted context omitted.

Since the VM system works at the granularity of pages, using N entirely different regions wastes up to $PAGE_SIZE * N bytes of memory just in the free space at the end of the region. You also make your fragmentation problem worse, since you can't place an allocation from one system within the free space of another.

Not suggesting that everything go in separate regions, but let's say they have N major functions (where N < 10) .. maybe physics, AI, render, network, etc. that would each run in their own address space. If N were even, say, 20 this still only comes out to 20 * 4KB (PPC page size) = 80KB, which I would classify as trivial.

You have to manage memory for things like textures, models, and maps - each of which are generally going to be way larger individually than 80KB.

Here's an example of a pathological - but entirely reasonable to encounter - case:

You allocate several textures of various sizes. Your larger 3MB texture blocks might end up seperated by smaller allocations for, say, icons. Or other 3MB textures that can be reused on the next level (to reduce load times). Long story short, unless you do work to ensure textures are correctly grouped by lifetime (which in many cases will depend on and diverge based on user input) you're going to end up with lots of 3MB holes.

You switch levels, and release many/most of your 3MB environment textures. But the icons remain loaded for your UI, so you don't free those. So now you have 3MB holes everywhere.

You start to load the next level. It's using a lot more alpha textures in it's environment - lots of water and glass. The alpha channels adds another 33% to the size - these new textures are mostly 4MB. None of these new textures fit into the 3MB holes. You've already potentially just wasted about half your available memory (or address space), with a single texture size in two formats of note. Within a single system ("render"). Oops.

Re: Memory and C++ Debugging at Electronic Arts [video]

#47

Post by pjmlp »

inDigiNeous wrote: post #41
melling wrote: post #2

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/128…

I can answer only for my own account, but for starting a new project in late 2013 december, and now been working for it the past two years, related to custom geometry generated in VR, C++ was the only viable crossplatform option. With C++ (using the C++11 standard) I can assure pretty sure that the code compiles on Mac, Linux, Windows, Android, iOS and pretty much every platform. With the VR -platform we also need al…

However that is a consequence of available implementations, not of the language itself.

Back in the day, I went Turbo Pascal -> C++ exactly for that reason (Turbo Pascal -> C was never an option).

If the UNIX systems I had to work with, had a Turbo Pascal compatible compiler, I would kept using it.

Re: Memory and C++ Debugging at Electronic Arts [video]

#48

Post by MaulingMonkey »

danjayh wrote: post #33
danjayh wrote: post #32

Earlier quoted context omitted.

Not suggesting that everything go in separate regions, but let's say they have N major functions (where N < 10) .. maybe physics, AI, render, network, etc. that would each run in their own address space. If N were even, say, 20 this still only comes out to 20 * 4KB (PPC page size) = 80KB, which I would classify as trivial.

Also of note is that fragmentation of physical RAM is completely irrelevant, aside from locality issues. They can map random physical pages into one nice, contiguous virtual space, and the only thing that matters is fragmentation in the virtual space. Since a each process gets its own entire 4GB virtual address space on a 32bit system, fragmentation nearly becomes a non-issue. This is also why I suspect that they wer…

> Since a each process gets its own entire 4GB virtual address space

2GB of which is reserved for kernel shenanigans unless everyone enabled /3GB in their kernel boot parameters (they haven't.)

Default allocators start failing at around half that amount.

Meanwhile I'm running out of memory on the new generation of consoles where I have 5GB of physical memory and no virtual memory fragmentation to worry about.

Re: Memory and C++ Debugging at Electronic Arts [video]

#49

Post by roghummal »

danjayh wrote: post #33
danjayh wrote: post #32

Earlier quoted context omitted.

Not suggesting that everything go in separate regions, but let's say they have N major functions (where N < 10) .. maybe physics, AI, render, network, etc. that would each run in their own address space. If N were even, say, 20 this still only comes out to 20 * 4KB (PPC page size) = 80KB, which I would classify as trivial.

Also of note is that fragmentation of physical RAM is completely irrelevant, aside from locality issues. They can map random physical pages into one nice, contiguous virtual space, and the only thing that matters is fragmentation in the virtual space. Since a each process gets its own entire 4GB virtual address space on a 32bit system, fragmentation nearly becomes a non-issue. This is also why I suspect that they wer…

I humbly suggest that if by some horrible twist of fate you had to work on games instead of "proper" software, you would quit programming.

Re: Memory and C++ Debugging at Electronic Arts [video]

#50

Post by bluecalm »

pandaman wrote: post #38
danjayh wrote: post #26

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,…

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 thi…

>>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?

Post reply on HN