• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Paul C Skertich

What improves better memory performance?

41 posts in this topic

Theres a big difference between
[code]List<Callback> toBeCalledAtLevelEndLeaveMeAloneUntilThen;[/code]
and
[code]Graph<RootObject> traverseMeEveryFrameMarkingReachedNodes;
List<EveryObject> traverseMeEveryFrameLookingForNonMarkedNodes;[/code]
Yes I've pitched the of simplest memory management against the dumbes non-generational mark-and-sweep GC, but the point is that for a lot of problems GC's or even smart-pointers are complete over-engineering. In my made-up straw-man, it's the difference between zero overhead per frame, and several milliseconds of cache-misses per frame, for no effect.

It's not evil, it may just be a lot more complex than is actually required.

Being a systems programmer, when I see anything with random-access memory patterns, such as a GC traversing an graph of all of your objects, it does conjure up the description of "god awful". On my last game we used Lua, which has a very simple GC. We had to customize it quite a bit, and then also re-write a lot of the Lua code to minimize garbage generation, in order to avoid random 8ms spikes in frame-times. We also ran it on a hyper-threaded core during rendering to try and soak up the GC cost for free, which helped, but it also trashed the cache-lines that the renderer was using, slowing it down too.

I'd still use them in the right circumstances, but with guidelines and care! Edited by Hodgman
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1347037520' post='4977725']
Being a systems programmer[/quote]
In my mind, this is really the crux of the matter. I don't disagree with any of your points, but I also am sure that you know enough to correctly implement an alternative to GC (i.e. careful manual resource disposal, or a robust scoped/smart_ptr solution).

A lot of programmers don't have that background, and a surprising amount of the time the garbage collector actually beats naive attempts to manually manage memory (i.e. for many small allocations, it performs much more like a pool allocator than does malloc/new).
2

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1347038971' post='4977741']
A lot of programmers don't have that background, and a surprising amount of the time the garbage collector actually beats naive attempts to manually manage memory (i.e. for many small allocations, it performs much more like a pool allocator than does malloc/new).
[/quote]Yep, and also avoids all the other nasties like leaks, dangling pointers and random memory corruption [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]

In some circumstances, Keep It Simple Stupid might mean "[i]just use the damn GC and don't try and reinvent the wheel[/i]", and in other circumstances, KISS might mean "[i]oh god why are you using another complex tree structure when you don't even need to be managing resources to solve this problem[/i]".

As usual generalisations turn out to not be useful [img]http://public.gamedev.net//public/style_emoticons/default/unsure.png[/img]
2

Share this post


Link to post
Share on other sites
See also:
Fixed-Size Block Allocator (FSBAllocator): [url="http://warp.povusers.org/FSBAllocator/"]http://warp.povusers...ator/[/url]
Boost.Pool: [url="http://www.boost.org/libs/pool"]http://www.boost.org/libs/pool[/url]

According to the FSBAllocator's benchmark using either the Boost.Pool allocator or the FSBAllocator might yield significant speed-ups over the default allocator for select cases (e.g., many small allocations that swiftcoder mentioned): [url="http://warp.povusers.org/FSBAllocator/#benchmark"]http://warp.povusers...ator/#benchmark[/url]

IMHO, the fact that you can do that (just plug-in a specialized allocator when you need it / when the defaults don't work for you) is a significant advantage over the one-GC-fits-all solutions (where, when the defaults don't work for you, the best you can do is to experiment with GC tuning). Edited by Matt-D
1

Share this post


Link to post
Share on other sites
[quote name='lawnjelly' timestamp='1347018916' post='4977578']
Well it would 'be nice' to be lazy and leave everything to a GC,
[/quote]

Sometimes the developer (or team) may not be quite skilled enough to have a choice and I hope to god that if working in a team, I wouldn't have to use some bodgy monstrosity.

In my spare time, I port software to FreeBSD and notice quite a few cases where developers have tried to hand roll their own stuff, nothing flags up bugs in this type of thing better than porting to an entirely new platform (and older version of GCC). So I suggest using a garbage collector unless you really know how to use the language properly.

While I havn't properly touched managed languages for well over 4 years, the Boehm GC works satisfactory on C++.

For software which needs no clever memory management however, the only solution is tr1/shared_ptr!. Edited by Karsten_
1

Share this post


Link to post
Share on other sites
[quote name='Karsten_' timestamp='1347045786' post='4977792']
For software which needs no clever memory management however, the only solution is tr1/shared_ptr!.
[/quote]
Or if you're using C++11, any of C++'s smart pointers (not in tr1).
1

Share this post


Link to post
Share on other sites
[quote name='Karsten_' timestamp='1347045786' post='4977792']
[quote name='lawnjelly' timestamp='1347018916' post='4977578']
Well it would 'be nice' to be lazy and leave everything to a GC,
[/quote]

Sometimes the developer (or team) may not be quite skilled enough to have a choice and I hope to god that if working in a team, I wouldn't have to use some bodgy monstrosity.

In my spare time, I port software to FreeBSD and notice quite a few cases where developers have tried to hand roll their own stuff, nothing flags up bugs in this type of thing better than porting to an entirely new platform (and older version of GCC). So I suggest using a garbage collector unless you really know how to use the language properly.

While I havn't properly touched managed languages for well over 4 years, the Boehm GC works satisfactory on C++.

For software which needs no clever memory management however, the only solution is tr1/shared_ptr!.
[/quote]

Yup, don't get me wrong, in almost the majority of apps I'd be all for using all the tricks in the book to make things simpler. Garbage collection, you name it.

Sorry if I come off as opinionated on the subject, I was a bit unfair on you Karsten .. I've had to deal with the mess caused in the past and it's not been pleasant. It's not very fair when people's jobs are on the line, and their families depending on them etc.

It's just in the specific case of (professional) games, particularly on fixed low memory devices (and some other software on embedded systems), my personal belief is that controlling the memory yourself can be the best option. That doesn't mean it's necessarily the best approach for people learning .. it's more an approach for making a solid professional product.

The two main reasons I would argue for this are:

Stability
Predictable timing

Stability - no worries about failed allocations .. your game will run each time, every time, no matter how many levels you load, what combinations of objects need to be loaded. There's no, ah but if character B walks round the back of building A, carrying object C and opens the door on level BLAH, then it crashes. Sometimes. Which is pretty much what you don't want to hear about when you are trying to ship something. Or what happens if someone is running such and such a program in the background in a multitasking environment.

Of course it's possible you could get round this to some extent with your Garbage Collection system - if it can allow you to pre-reserve your memory, (depending on its implementation regarding fragmentation), and if you keep a tight handle on your numbers of various objects. But once you get to this extent you are almost doing the work of doing it yourself anyway.

The other is that there is no question over the time taken over a deallocation / allocation. It is determined by your code and can be tightly determined - usually a constant very short time. There's no worry about dropping frames etc. Using a third party allocation / deallocation system leaves you at the mercy of their implementation. That's not to say there aren't good implementations, but there are also bad ones, and worst cases. Windows for example is quite happy to grind to a halt and do some disk swapping when it thinks it's necessary during an allocation / deallocation.

I fully understand that it can be a bit of extra effort (sometimes quite a bit) to manage memory yourself, although it's usually mainly a one off cost setting up your project. But development isn't just the time putting the code together, it's also beta testing, trying lots of different scripts, game levels, combinations of factors. In this situation the more potential problems you can remove the better.

If you are working to a time schedule with milestones and a budget and staff costs to pay, the last thing you want is some vague uncertainty over 'yeah it may take 2 years to beta test this thing'. That's one of the (several) reasons why games get canned / companies go under.

But anyway at the end of the day it's up to whoever is technical lead on a project to make these kind of decisions. Right I'm tired that's enough essaying it's bedtime! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
1

Share this post


Link to post
Share on other sites
[quote name='lawnjelly' timestamp='1347050343' post='4977804']
The other is that there is no question over the time taken over a deallocation / allocation. It is determined by your code and can be tightly determined - usually a constant very short time.[/quote]
So, I mostly agree with the rest of your post, but this point isn't quite as straightforward as you suggest.

Malloc/new are [b]not deterministic[/b]. The cost of an individual allocation is generally much higher than that of a garbage collector, and it is [b]not a fixed cost[/b]. But you do get the (to my mind, dubious) benefit that the performance cost is incurred at the call site (whereas garbage collection incurs a performance cost at an indeterminate later date).

If you actually need deterministic allocation cost, then you have to go with other solutions (probably ahead-of-time allocation: pool allocators, SLAB allocators, etc.)
1

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1347047025' post='4977795']
Or if you're using C++11, any of C++'s smart pointers (not in tr1).
[/quote]

Agreed, although I did mention I was using an older version of GCC (due to the old BSD compatible license). When possible I will always take advantage of newer features of the C++ language!

[quote name='lawnjelly' timestamp='1347050343' post='4977804']
Sorry if I come off as opinionated on the subject, I was a bit unfair on you Karsten .. I've had to deal with the mess caused in the past
[/quote]

Heh, no worries. I seem to be on the wrong side of this argument anyway because I am usually the first to advocate the use of manual memory management, RAII and simple clean solutions. ;)

I find deterministic destruction plays a much bigger part in my software than simply cleaning up memory too. For example if a unit of execution (i.e a thread) is running within a class (or containing references to), then this will never be flagged for disposal by the GC. This I find is quite a critical design flaw within most GC languages since what I really want to happen is once the object goes out of scope, the class should join the thread and deallocate in an elegant exception safe manner.
The only .NET language that seems to support this is C++/CLI since you can use auto_handle<T> as a means to implement the RAII pattern.

Slightly offtopic...
I dont know if anyone else noticed that Apple has recently deprecated garbage collection in 10.8 for their objective-c. Quite an interesting decision showing that perhaps they feel that manual memory management (or reference counting) isn't much harder than relying on a GC or at least that the performance will be superior etc....
[url="http://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html"]http://developer.app...troduction.html[/url]

"Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X" Edited by Karsten_
1

Share this post


Link to post
Share on other sites
"INTERIOR DEBATE ROOM - NIGHT TIME"

AS THE SMOKE CLEARS, A BIT OF HAZE STILL DRIFTS JUST LINGERING ON THE FLOOR.

Is everyone finished? Cool, Group Hug Everyone! Com'on!
0

Share this post


Link to post
Share on other sites
[quote name='Karsten_' timestamp='1347055668' post='4977831']
I dont know if anyone else noticed that Apple has recently deprecated garbage collection in 10.8 for their objective-c. Quite an interesting decision showing that perhaps they feel that manual memory management (or reference counting) isn't much harder than relying on a GC or at least that the performance will be superior etc....
[url="http://developer.app...troduction.html"]http://developer.app...troduction.html[/url]

"Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X"[/quote]
Not quite.

Yes, Objective-C garbage collection is being removed (and was never that widely used to begin with, partly because of the lack of iOS support).

However, as your link indicates, Apple is replacing it with a system called [url="http://longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/"]'ARC' (Automatic Reference Counting)[/url]. Effectively, [url="http://clang.llvm.org/docs/AutomaticReferenceCounting.html"]they have modified their compiler to spit out all those retain/release calls for you[/url], and it does a much more reliable job of it than a human could.

I wouldn't really call that 'manual memory management'. It's still a fully automated garbage collector, just one based on internal reference counting (similar to Python's old garbage collector).

And sadly, it suffers from the age-old deficiency of reference-counting systems: the need to explicitly annotate weak references. Edited by swiftcoder
1

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1347052581' post='4977811']
[quote name='lawnjelly' timestamp='1347050343' post='4977804']
The other is that there is no question over the time taken over a deallocation / allocation. It is determined by your code and can be tightly determined - usually a constant very short time.[/quote]
So, I mostly agree with the rest of your post, but this point isn't quite as straightforward as you suggest.

Malloc/new are [b]not deterministic[/b]. The cost of an individual allocation is generally much higher than that of a garbage collector, and it is [b]not a fixed cost[/b]. But you do get the (to my mind, dubious) benefit that the performance cost is incurred at the call site (whereas garbage collection incurs a performance cost at an indeterminate later date).

If you actually need deterministic allocation cost, then you have to go with other solutions (probably ahead-of-time allocation: pool allocators, SLAB allocators, etc.)
[/quote]

Ahha .. this may be where the confusion lies.

I didn't want to suggest 'using malloc / free at runtime is better than garbage collectors'. Far from it... they both have related downsides.

In c++, if you override new, you don't need to use OS calls for memory management. You can use whatever system you want for grabbing memory from wherever you want, then you have the opportunity to call the constructor yourself with placement new. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

In addition there is a distinction between one off allocation / allocations at startup, and their corresponding deletion at shutdown, and dynamic use (i.e. the kind of things you might use lots of times in a frame). The second case is what we are interested in here. For actually reserving your memory at startup, you could use whatever you want .. an OS heap, garbage collected system. Ultimately your memory has got to come from somewhere. [img]http://public.gamedev.net//public/style_emoticons/default/happy.png[/img]

(There is also the slightly less stringent case of level load / unload, where you *could* if necessary be a bit more lenient / take some shortcuts on some platforms).

What we are after in games, in an ideal world, for dynamic allocation (things that happen a lot rather than just startup and shutdown) is stability (no failed calls) and constant time (and fast) allocation and deallocation. [img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img]

Sorry I should have been more clear on this. I would on the whole use things like fixed size memory allocators (and potentially other constant time allocators) for things that need to be created / destroyed dynamically (see my first post on page 1). You can use this for constant time incredibly fast allocations / deallocations, suitable for things like nodes in algorithms, even particle type systems.

For things that are truly variable size (levels etc) the tradeoff can be to prereserve space at startup for worst case, and work with that. Alright you lose a bit from the theoretical maximum, but you gain in simplicity and stability. On levels with not much geometry, you can e.g. add more sound, or more textures, and vice versa. For your level file you can prepack into the best format possible, with zero fragmentation, and make use of the whole of your budget in megs. If you need to use more than this, then you need to support streaming of level data on the fly (this is a whole other topic with similar concerns, guess what, you can use fixed size bank slots for this too!).

You can do this for GPU resources too .. reserve e.g. 5000 verts for a character and then stick to that budget or lower for your artwork, and you can guarantee they will always fit in that 'slot'.

You can also pre-designate blank 'slots' for various items in the level data RAM allotment to give more flexibility, if it seems a better idea than deciding ahead of time the maximum number of item 'blah'. If you do this you get the benefit of zero fragmentation, and best use of memory for that level.

In short there are lots of handy 'helper' bits of functionality offered to programmers, like 'general purpose' heaps, variable size strings etc. There are whole languages dedicated to making things 'easier' for the programmer where these things are a given (basic, php etc etc). In most situations this is a real benefit because it makes you much more productive as a programmer - less code, simpler code, less potential for bugs, and the 'costs' are not going to appear to the user.

It's just that in some situations, particularly time critical applications, and those on limited memory devices, it can become worth it to not use some of the helper functionality. An extreme example would be missile control software. You might have limited memory. If your program crashes, people die. If your program takes too long to faff around restructuring the heap, people die. It's only if it works predictably and as per spec that the right people die.

Other examples where you have to be a bit more stringent include things like financial software, medical software, some engineering software.

Would you want the nuke heading towards your neighbours house programmed in java with garbage collection, or c++ with no external allocations? I know know which one I'd rather have heading towards my neighbours. [img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img]

[i](edit) Some good search terms to google in this area are : 'real time programming', and 'mission critical programming'. (/edit)[/i]
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1347108149' post='4977963']
stuff
[/quote]

Yup, that's pretty much how we ended up doing it too! Snap lol. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] I think it probably ended up as a malloc on a reserved heap on pc build for the level file, and just loading into the prereserved block on consoles.

For the streaming I think I had more chunks (I called them banks), maybe 8 or 16 something like that, then parts had the option to use e.g. 2 banks worth.

For deciding which banks needed to be loaded I used a PVS calculated from the artist's levels and portals, and a potentially loadable set derived programmatically from this. There were areas though I'm sure where the artists had overcooked it and they needed to put in visibility blocks of some kind. I think the tool chain alerted them to this. Worked a charm, especially with decent asynchronous streaming support.

Getting way off topic though there hehe! [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0