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

61–70 of 71 posts

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

#61

Post by melling »

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…

This is completely irrelevant to the question. Furthermore, most of the code was written a decade ago. Why can't I use Go, for example?

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

#62

Post by e12e »

lorenzhs wrote: post #58
e12e wrote: post #16

Earlier quoted context omitted.

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…

Your search query needs escaping for the pluses, otherwise it will match 'implemented-in::c' as well (aptitude's matching is weird).

Whoops, you're absolutely right. Eg:

  '?tag(implemented-in:c\+\+)'
On a different desktop right now, so can't check -- but that'll probably lower the count considerably (eg: on a different server I get 226 for "c/c++" and 19 for just "c++" ("c\+\+)").

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

#63

Post by lispm »

kayamon wrote: post #45
Zardoz84 wrote: post #40

Earlier quoted context omitted.

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.

Lisps without GC have been used in various places for delivery.

An example was Thinlisp, which tries to be mostly compatible with Common Lisp, but without GC. The compiler for Thinlisp is written in Common Lisp.

G2's Gensym is written in such a Lisp. Thinlisp also comes from them, IIRC. http://www.gensym.com

Some Lisp don't/didn't use a GC, but reference counting or similar schemes.

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

#64

Post by vectored »

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 use C++ in my work - robotics/Comp-vision. We need it for the performance and the cross-platform characteristics. It is a highly powerful language once you get used to its complexity. In my experience, it is the most popular language in the robotics community, though not for prototyping (Matlab, python are more common for prototyping)

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

#65

Post by StephanTLavavej »

Flow wrote: post #56
StephanTLavavej wrote: post #30

Earlier quoted context omitted.

Yes, both MSVC's front-end C1XX and back-end C2 (aka UTC) are written in C++. Even our CRT is mostly C++ now.

Do you update it to follow the latest standards or is it early 2003-ish C++?

C1XX uses new features fairly aggressively. For example, it uses lambdas, auto, range-for, etc.

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

#66

Post by danjayh »

corysama wrote: post #43
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…

you actually get 4 gigs per process, so you could have 64 spaces of 4 gigs each, with the 256mb of physical ram mapped into those spaces as needed.

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

#67

Post by danjayh »

MaulingMonkey wrote: post #46
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.

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

OK. So the issue is the GPU then. That same scenario with data that could use virtual memory would be a non-issue, since you could mash the available fragmented phsyical ram together into whatever size blocks were needed using the MMU.

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

#68

Post by danjayh »

MaulingMonkey wrote: post #48
danjayh wrote: post #33

Earlier quoted context omitted.

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.

Truth on the kernel. I'm used to working in an environment where we own the OS, the board design, and the design of many of the chips ... which means we can make it do whatever we need (downside is, you have to maintain it all too). However, our needs are unique enough to justify it -- computing is hard in an environment where atmospheric radiation can flip random bits for you (See: https://en.wikipedia.org/wiki/Single_event_upset).

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

#69

Post by corysama »

danjayh wrote: post #66
corysama wrote: post #43

Earlier quoted context omitted.

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…

you actually get 4 gigs per process, so you could have 64 spaces of 4 gigs each, with the 256mb of physical ram mapped into those spaces as needed.

No app-space multiprocessing on consoles. The OS is extremely minimal. In the PS2 days, there was no OS. Just the BIOS and a few standard libraries to statically link.

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

#70

Post by MaulingMonkey »

danjayh wrote: post #67
MaulingMonkey wrote: post #46

Earlier quoted context omitted.

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

OK. So the issue is the GPU then. That same scenario with data that could use virtual memory would be a non-issue, since you could mash the available fragmented phsyical ram together into whatever size blocks were needed using the MMU.

> That same scenario with data that could use virtual memory would be a non-issue

Untrue I'm afraid - the case I'm basing this example off of could (and did) happen in virtual address space as well.

> since you could mash the available fragmented phsyical ram together into whatever size blocks were needed using the MMU.

Okay, so your physical memory is no longer fragmented. Unfortunately, your virtual address space still is. If I need to allocate a 3MB contiguous chunk of virtual address space (I do), I'm still SOL.

All the MMU gains you in this respect is a "free" memcpy - twiddle some MMU bits instead of copying data around from one buffer to another. It won't fix up any of your pointers.

Post reply on HN