Memory and C++ Debugging at Electronic Arts [video] • Hacker News Board

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

#11

Post by davidgrenier » Thu, Oct 08, 2015, 3:03 AM UTC

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) which Google might very well be starting with the recent efforts on the Go garbage collector.

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

#12

Post by denim_chicken » Thu, Oct 08, 2015, 3:08 AM UTC

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…

Such naivety.

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

#13

Post by kayamon » Thu, Oct 08, 2015, 3:29 AM UTC

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

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

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

#14

Post by wsxcde » Thu, Oct 08, 2015, 3:34 AM UTC

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?

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

#15

Post by duaneb » Thu, Oct 08, 2015, 3:41 AM UTC

wsxcde wrote: post #14

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?

> Is it just because they don't want to store an extra pointer with each block?

I would imagine; this could add up quickly with an e.g. linked list.

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

#16

Post by e12e » Thu, Oct 08, 2015, 3:50 AM UTC

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…

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

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

#17

Post by kayamon » Thu, Oct 08, 2015, 3:54 AM UTC

wsxcde wrote: post #14

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?

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

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

#18

Post by wsxcde » Thu, Oct 08, 2015, 4:04 AM UTC

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 a fair amount of C++ for my code and its entirely because all the other tools I use - SAT solvers, model checkers, etc. are written in C++. I don't like it very much and many others in my community don't like either, but we're all stuck in this local maximum.

Moving to an entirely new language is impractical for any single project so all the new projects end up using C++ which in turn means the projects that come after them ending up using C++ as well. For a concrete example, look at something like ABC (https://bitbucket.org/alanmi/abc). There is very little incentive to rewrite the whole thing in a safe language but if you're doing new circuit verification research having ABC's humongous library of transformations and verification algorithms will be a huge help in implementing new things.

There have been a few attempts to break away though. Some folks at SRI wrote the model checker SAL in Ocaml, a lot of CMU folks seem to like Ocaml too: for example the bitblaze project uses Ocaml. And z3py has helped make Python popular.

I've lost countless hours of my life debugging the sorts of issues this guy is talking about, so I really hope we do make the switch to something better.

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

#19

Post by vvanders » Thu, Oct 08, 2015, 4:15 AM UTC

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

See my comment below, GC isn't the problem. It's being able to layout your memory appropriately so you don't cache miss which when everything is a single heap allocation becomes almost impossible.

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

#20

Post by vcool07 » Thu, Oct 08, 2015, 4:29 AM UTC

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…

No, C/C++ is still very commonly used in many real time systems, embedded systems etc. But, since most of the topics in HN are in the web/android/ios areas, you might not see many devs talking about it here. C/C++ (esp on linux/RTOS) still has a very active user base and market demand !