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

31–40 of 71 posts

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

#31

Post by adrianN »

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…

Check out this talk by Herb Sutter https://sec.ch9.ms/ch9/ddaf/d4642f30-491c-481d-97c5-62aa5ab6...

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

#32

Post by danjayh »

panic wrote: post #27
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,…

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.

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

#33

Post by danjayh »

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.

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 were mapping their virtual address space using block translation instead of a page table - if they had a page table, even in one process, it shouldn't have been a big issue since the virtual address space is many times larger than the available physical ram on the 360/PS3/Wii. The other possibility is that much of their RAM needs to be accessible by the GPU, for which fragmentation is an issue.

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

#34

Post by danjayh »

nikanj wrote: post #29
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,…

By running everything in a single process and address space they can get n % more fps, where n>0.

Perhaps, but it's possible that it was actually the other way around since Virtual Memory and multicore came at about the same time. By running everything in a single process, they probably avoided forcing clean interfaces and dependencies between their functions, which might have actually hurt their ability to utilize the CPU efficiently.

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

#35

Post by pjmlp »

z3phyr wrote: post #8
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…

A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is pro…

I like C++, but I am also quite older than the language and remember when the language was seen as unsuitable to write any of those systems you have mentioned.

Eventually it got adopted by people like myself that didn't care for the naysayers and its compilers improved to the point many think it was always like that.

Likewise others will use languages that the naysayers of today won't see as proper to write them and in ca 20 years from now, everyone will think they were always that way.

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

#36

Post by Kristine1975 »

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…

Here's Tim Sweeney of Unreal fame talking about GC: http://lambda-the-ultimate.org/node/1277#comment-14252 (granted, it's from 2006, but I still think it's relevant)

TL;DR: It's not a problem.

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

#37

Post by pjmlp »

plexchat wrote: post #3
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…

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…

C++ isn't the only language that offers such garanties.

What it is, is the 90's survivor of all wannabe C replacements.

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

#38

Post by pandaman »

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

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

#39

Post by lultimouomo »

e12e wrote: post #16
z3phyr wrote: post #8

Earlier quoted context omitted.

A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is pro…

AFAIK Debian isn't very diligent about tagging packages with "implemented-in", but even so: dpkg -l |grep ^ii -c #Installed packages 3608 # packages tagged as being in c++, and installed: aptitude search '?tag(implemented-in::c++)' \ |grep ^i -c 930 I'm sure there's lots of c++ in the other 75% (or they depend on a runtime/compiler/library written in c++) -- but at any rate - one in four packages is nothing to sneeze…

Linux is more of a C than a C++ land, so the figure does not look unreasonable to me.

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

#40

Post by Zardoz84 »

kayamon wrote: post #13
davidgrenier wrote: post #11

Earlier quoted context omitted.

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

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.
Post reply on HN