• 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

What imrpoves performance in memory management? By using the keyword New or malloc? What if one allocated memory doesn't get deleted - will it literally screw the memory leaving it too fragmented or after the computer restart the memory will automatically free anything it has resides?

New and Malloc are termed as Heap, right? Stack Heap, Pool Heap - etc?

Have a great day everyone! I wanted to know about your perspective on better performance in memory.
0

Share this post


Link to post
Share on other sites
Try to avoid new or delete. Allocating memory from a pool of heap is a very slow operation.
Automatic variables are much faster
0

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1346950016' post='4977265']
New and malloc are both used for dynamic memory allocation on the heap, new is C++ specific while malloc is available in both C and C++. Mixing of both new and malloc in C++ is heavily discouraged, so it's best to stick to the new keyword for standard dynamic memory allocation in C++.

Not releasing memory with free or delete causes what we call a memory leak when said memory becomes unreachable (ie. the application has no access to a pointer which points to this memory). The memory is now unavailable for use by both your application and the operating system, and thus cannot be reassigned to another application for as long as the original application is running.
When the original application exits however the operating system will reclaim all memory allocated by that application. This however does not mean that you shouldn't take memory leaks seriously as they are still potentially hazardous.

Memory fragmentation is an issue which will occur in standard dynamic allocation whether you have memory leaks or not, chunks of memory which are all allocated in one new or malloc call however will be contiguous in memory. The only way to completely remove memory fragmentation is by doing linear allocation on a pre-allocated memory pool for example (like when working with the stack), but this allocation scheme is absolutely not suited as a general purpose allocator.


These concepts are all very elementary C++ concepts. I know you're writing a game engine, so I find it very odd that these things are new to you.
[/quote]

Yes, I understand the concepts are elementary - within 3 months now I've been refreshing my knowledge in C++. I've not touched C since I was 7 years old. Teenage years I've been mostly in HTML, PERL, and other web-based programming. 2001-2011 I've been not programming because getting over depression and couseling sessions. 2011, met my wife and happy as a clam. So, yes; I'm refreshing quickly as possibly to catch up with the professional game industry. It's not crazy to remember pieces of code from a dream. I woke up last night from a dream discussing about TCHAR with another person in my dream. Guardian Angels sending some kind of crytic message - who knows. All I know is I got to catch up to the professional game gurus. This is why I'm obtaining every bit of information possible - John just didn't wake up and say "Doom - 3D first game engine. I have all the code inside my brain." He had to learn it from books; from others; from other sources and trial and error. Albert Einstein was perhaps showed the formula that would equate to E=MC squared. I'm a spiritualist; my views may differ upon others spiritual views on the forum.
0

Share this post


Link to post
Share on other sites
So, a rule of thumb is to consistantly make sure no memory leaks because it can cause performance slow down. Got it. Additional notes, keep proper heaps so there's less fragmentation in memory - got it.
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1346973336' post='4977412']
[quote name='Radikalizm' timestamp='1346950016' post='4977265']
The memory is now unavailable for use by both your application and the operating system, and thus [b]cannot be reassigned to another application[/b] for as long as the original application is running.[/quote]
This is not really true on desktop operating systems. In practice, when some other process needs more memory than is currently available, the virtual memory system will stash a few of your memory pages to disk, and grant that physical memory to the other process. Obviously, this is all pretty transparent to both applications.

On a console or mobile device, there often isn't a virtual memory system, in which case your statement is correct.
[/quote]

Well yeah, but for simplicity's sake I thought it would be better not to include an explanation of how paging works as it wasn't needed to explain the basic idea of a memory leak :)
1

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1346973336' post='4977412']
[quote name='Radikalizm' timestamp='1346950016' post='4977265']
The memory is now unavailable for use by both your application and the operating system, and thus [b]cannot be reassigned to another application[/b] for as long as the original application is running.[/quote]
This is not really true on desktop operating systems. [...relevant stuff...]
[/quote]
This is kind of splitting hairs. I think you're focusing more on the physical RAM (i.e. where your memory is), whereas Radikalizm I think was focusing more on the "big picture" of overall memory use (where you have a limited amount to work with on a computer, regardless of where that virtual memory physically is). So I'd say you're both right and both bring up good points.
1

Share this post


Link to post
Share on other sites
It's okay guys! It's all good! It's all good advice because Virtual memory is good to know when creating a game to work on Desktop; and different allocation way to handle of memory for a mobile and a console game. I think it'll be just best practice to ensure that I deallocate the memory - if I ever do port the engine to a console or phone. It's just good practice I think. Regardless of virtual or just physical - I think it just shows proper effective coding. Which I gotta get the ebook of Effective Coding on amazon. Currently, I'm aiming at effective and proficient coding techniques.
0

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1346974414' post='4977423']
where you have a limited amount to work with on a computer, regardless of where that virtual memory physically is[/quote]
On your average 64-bit desktop with a 500+ GB harddrive, you could easily use [b]several hundred gigabytes[/b] of memory - despite only having < 16 GB of physical RAM (you also may be able to allocate several [b]terabytes[/b] of memory, provided you don't actually write any data to it).

My point is that you don't free memory on a desktop OS because you are worried about running out, you free memory to avoid the performance hit caused by unnecessary paging.
2

Share this post


Link to post
Share on other sites
[quote name='SIC Games' timestamp='1346972605' post='4977407']
So, a rule of thumb is to consistantly make sure no memory leaks because it can cause performance slow down. Got it. Additional notes, keep proper heaps so there's less fragmentation in memory - got it.
[/quote]

"Got it" ... but do you understand the reason? If you're trying to learn, you should be able to explain why.

I actually don't think anyone said memory leaks cause a performance slow down. That's kind of a vague statement anyway. A more accurate, concrete statement would be that memory leaks can cause future allocations to fail because there will no longer be sufficient virtual memory left (although on a 64-bit machine, this may take "forever"). So your program will run out of memory and crash or lose functionality or end up in a corrupt state (depending on how well you handle the allocation failures). However, on the way there, it could likely cause performance problems if there is a lot of paging to disk.

Someone did say that lots and lots of small heap allocations (regardless of whether you're leaking the memory) could cause performance issues, and that is true. Allocating from the heap can be a *relatively* slow operation in c++. It's not typically something you should be worried about at this stage though.

It's definitely more than "best practice" to ensure that you deallocate memory. It's necessary if you are writing any quality code - something you'd want to ship and have other people use. Edited by phil_t
2

Share this post


Link to post
Share on other sites
Hate to say it, but this where I think GC languages like Java and C# do quite well.

Basically rather than allocating and deallocating memory as they go along, they allocate the memory but then only deallocate at certain points and in which case they clean up a lot of memory in one pass which is ultimately quicker.

If you do look into memory pools, stuff can get quite complicated so sometimes it might be nice to leave it to the GC platform's memory pool.

Frankly I prefer the simplicity of smart pointers, but they are ultimately "inefficient".
By using C++.NET you can perhaps get best of both worlds, by using auto_handle<T> to get deterministic disposal of memory to implement patterns requiring RAII but also garbage collected memory using gcnew. Edited by Karsten_
1

Share this post


Link to post
Share on other sites
Phil_t, I can easily comprehend than what what you are saying. Yes, it is a necessasity in coding to ensure to deallocate memory regardless of what OS. I don't care if a person is running a HAL 9000 or whatever - still inside my mind it's proper coding effectiveness. Everyone is right due to their opinion based on experience. So, yes I "got it" and I comprehend. If I was a bit confused - I would ask more questions; right? That's what a person learning would naturally do, right?

Good job everyone for giving some handful advice. This is why you have I've gave you positive reputation points.
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1346988655' post='4977479']
GC's are absolutely horrible in games.
[/quote]
For hard real time, it is definitely a problem. For soft real time, there are possibilities. It depends on whether a game is hard or soft real time. Action games, like shooters, that depend on a steady FPS and consistent repeatable responses may certainly be a problem.

I have a MMO RPG server designed to support 10000+ players. Being a RPG, rather than a shooter, lowers the requirements. The server is programmed in Go, which is entirely based on garbage collection. Doing tests for 1000 players shows a steady load of approximately 10% on the target machine. True, it is a synthetic test, and not a proof that it will work in a real situation. But it looks very promising so far. I should also admit that the design of the server has been influenced by the GC mechanism. That is, data is preferentially re-used instead of thrown away. But that is not different to usual C/C++.

I think the aversion against GC is a little too strong here and there. Especially from card core C/C++ programmers.
1

Share this post


Link to post
Share on other sites
Fixed size memory pools FTW. They are great.[img]http://public.gamedev.net//public/style_emoticons/default/cool.png[/img]

The downsides are you have to (typically) know in advance how many of the objects maximum you will want worst case scenario. In addition the memory preallocated for the pool is not available for other uses.

Upsides are they are blazingly fast, constant time allocation and deallocation, there is no fragmentation, and provided you choose the maximums correctly your program CANNOT crash due to an allocation failure.

You can also implement your own heap with buckets but it's not something I'm a fan of.

You can also (in c++) override new and delete to keep track of your allocations. You can use different heaps / counters for different modules, and budget your memory between them. Very useful on consoles and limited memory devices. This can also report to you any memory leaks on closing, which module and which file they are from.

Other tricks are things like, when you load in a game level, load it as a binary file laid out in usable form in memory. Then fixup the pointers within it from offsets within the file to actual locations in memory. This gives you super fast loading, no fragmentation, and cache coherency. And of course level size etc is one of the biggest 'changables' within a game, so if you can isolate this down to one allocation, you shouldn't really need to do much else in the way of allocation. And even for this you can just pre-allocate a big chunk for the biggest level size, that's what I've tended to do on console-like environments.

Of course this is for game code, where stability and speed are paramount. For tools and apps I'll be a lot more lax, and use dynamic allocation etc (sometimes I don't even override new and delete, when I'm feeling like living life close to the edge [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] ).

It's also worth mentioning that there are some allocations you can't avoid, depending on the OS - API allocations such as directx and opengl. You can of course use pooling systems with your API resources too. In addition on consoles you can often completely avoid this problem by using a resource directly from memory as they may be UMA or give you more control over memory.
2

Share this post


Link to post
Share on other sites
Have to say I'm with Hodgman on this one.

Using OS calls for allocation and deallocation at runtime in a game is one of the cardinal sins, but GC too? Urggg!! Do you know what these calls do behind the scenes? I wasn't even going to mention it.[img]http://public.gamedev.net//public/style_emoticons/default/wacko.png[/img]

[quote name='Karsten_' timestamp='1346977976' post='4977444']
If you do look into memory pools, stuff can get quite complicated so sometimes it might be nice to leave it to the GC platform's memory pool.[/quote]

Well it would 'be nice' to be lazy and leave everything to a GC, but unfortunately there are reasons why people don't tend to use this kind of thing for time dependent stuff. I understand looking after memory is 'an extra bother' and 'complicated' but it's necessary if you want to make fast, stable code. I've also had to spend weeks sorting out problems caused by 'programmers' who thought memory management was 'a bother', and delayed shipping products, and left them bug ridden messes.[img]http://public.gamedev.net//public/style_emoticons/default/dry.png[/img]
1

Share this post


Link to post
Share on other sites
[quote name='lawnjelly' timestamp='1347018916' post='4977578']
[b]Do you know what these calls do behind the scenes?[/b][/quote]
Yes, I do (and my guess would be so does Hodgman, and a vast number of other people on this forum).

And that's a key issue when it comes to performance in general, not just where garbage collectors are concerned - you need to understand what goes on under the hood.

Don't fear the garbage collector just because you don't understand it. Odds are that if you don't have the knowledge/skills to rewrite the garbage collector from the ground up, you also don't have the knowledge/skills to beat it at performance.
1

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1347033663' post='4977693']
[quote name='lawnjelly' timestamp='1347018916' post='4977578']
[b]Do you know what these calls do behind the scenes?[/b][/quote]
Yes, I do (and my guess would be so does Hodgman, and a vast number of other people on this forum).[/quote]I took that sentence as a rhetorical question -- as in, [b]these calls do god awful stuff behind the scenes![/b]
1

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