Skip to main content
gamedev.net
🔒 Locked

Memory Management ?

Started by FxMazter 9 replies 650+ views
Original Post
FxMazter
FxMazter
Ohoi again Well, recently I read an article here on memory management. I know about some concepts, mainly the "buddy" concept. But what I don't actually understand is WHEN I am supposed to use this concept? Suppose I make my own MemoryManager that allocates chunks of memory in different sizes right? Now, when am I supposed to use this? I guess, that since the memory is already allocated it will take less time to use this than using the "new" operator, which could be good in certain processes, like with heavy graphics stuff? But then, I could just as well have a memory manager that - lets say - allocates 64mb of memory and then all the objects in the engine will get the already allocated memory from this manager, and in case the aplication needs more memory the manager simply allocates another 32mb or whatever? Now would this be any good? or is it simply better to go on and use the standard "new" annd "malloc" ? Cmon, give me some feedback on this. Some ideas when to use such a MemoryManager and when not - that means if to use it at all ? [edited by - FxMazter on January 7, 2004 1:05:02 PM] [edited by - FxMazter on January 7, 2004 1:05:42 PM]
evolutional
evolutional
Take a look at enginuity and it''s MM. I use a custom implementation of Richard''s ideas and it works nicely.

Especially the auto cleanup. Even though it''s made me lazy ;P
FxMazter
FxMazter
Yes, I have looked at his articles... and I am using a similar system to his. But he isn''t actually allocating any memory during initialization... he uses the new allocator or whatever...

I was thinking of having a similar MemoryObject to his... counting references etc... and automatic cleanup. But thats not the thing I was wondering.

What I was thinking about in addition, was having a class that basically allocates memory, the free memory which normaly is slow to allocate during runtime. Now this manager would contain loads of memory and whenever any object would need dynamical memory... it would just ask this manager for some amount.

This way I would get rid of all the allocations during runtime right? So, If I need to allocate 50 000 vertexes then I wouldn''t need to allocate it, I would just ask the manager for it and tada... the code is speed up enormously right?

evolutional
evolutional
The problem is, you''d be allocating a HUGE block of (probably unneccessary) memory when your program runs.

It''s like buying 20 pies at a pie shop because you might be hungry, but only eat 2 of them.
MonkeyCookie
MonkeyCookie
I was originally going to use a memory management system like in enginuity, but I then found the Boost C++ smart pointer library, which takes care of memory managment for you. I believe it uses some kind of reference counting system, deleting an object when nothing references it anymore. I haven''t actually started using it yet, but it seems to be simple to use.

The smart pointer library can be found here:
http://www.boost.org/libs/smart_ptr/index.htm

You most likely would want to use shared_ptr and shared_array.

psykr
psykr
Before you write a memory manager, stop and think about what you''re doing. Writing one that just does reference counting / garbage collection (i.e. no custom allocation schemes) isn''t that much of a hassle, go for it.

But writing memory managers that allocate from a memory pool, or anything like that is wickedly mind-numbing. Unless you''re allocating something crazy (like thousands of byte-long chunks per second), there probably isn''t any need to write a custom memory manager.
blizzard999
blizzard999
quote:
Original post by FxMazter

But then, I could just as well have a memory manager that - lets say - allocates 64mb of memory and then all the objects in the engine will get the already allocated memory from this manager, and in case the aplication needs more memory the manager simply allocates another 32mb or whatever?


Yes...if you finish allocated memory you probably need a new (and possibly big) chunck. So you have a list of chuncks in which every chunck contains a block of memory ''exported''.

quote:

Now would this be any good? or is it simply better to go on and use the standard "new" annd "malloc" ?


In some situation you need to alloc/free a great number of objects...in this case a memory manager can be faster and avoid fragmentation.
In the special case in which you have a lot of objects of the same size (for example particles) you can achieve an allocations/deallocations istantaneously! This situation is also simply to manage using lists of equal sized chuncks (this is also the fastest solution).



antareus
antareus
Boost has a memory pool implementation that would be worthwhile to look at.

I use new/delete normally until memory allocation shows itself to be a problem (through memory leaks or performance). It is actually surprising how little time is spent doing heap allocation in a release build.

quote:
avoid fragmentation

I often see this quoted as an advantage to memory managers, however, does anyone have any data that confirms this?

[edited by - antareus on January 7, 2004 2:38:36 PM]
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
jamessharpe
jamessharpe
A big reason you''d want to create a custom memory manager for is for implementing a cache. Achieving seamless worlds, will require you to have a cache of some sort even if it''s just for the video memory. The advantage to having a pre allocated chunk of memory for all your vertex data is that the memory is contiguous. This means that accessing the memory is going to take less time since it takes advantage of the caching system of modern computer architecture. I think that use of new for regular objects is fine, it''s for the stuff that''s used in time critical operations that probably needs a memory pool system. For example I have a render queue which has a small Link class, that it allocates to hold an item in a renderqueue. Now with new, this was taking up a substantial amount of time during rendering, but by creating a pool and overiding the new and delete for the class I was able to achieve a noticable increase in speed - the frame rate doubled(at least)

James
coelurus
coelurus
If you have the time to write a memory manager, go for it, they can help a lot. They''re quicker, I''ve found leaks using mine and it feels good when you''ve made one I don''t know about fragmentation, but messing up the memory with a lot of strings everywhere feels bad. Of course, if you don''t need one and don''t feel like making one, skip it.
antareus
antareus
quote:
but messing up the memory with a lot of strings everywhere feels bad. Of course, if you don''t need one and don''t feel like making one, skip it.

VC 6.0''s std::string implementation is reference counted.

VC 7.x''s std::string implementation uses a character buffer for strings up to 16 characters that is allocated on the stack.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.