Comments on: Ready, Set, Allocate! (Part 4) Hi Markus, The unsafe method with a heap parameter, sounds similar to what we used in our engine at Savage Entertainment. One of the things we did was to have static sizes defined for the heaps, on a per level/map basis; this has pros and cons, as does everything. ;) The biggest pro I can remember was that we could tune the heaps to balance for very different memory requirements from level to level, or map to map, depending on the game style. The biggest con was that we were constantly trying to figure out just how small we could get away with making each heap, every time a change was made in the designer's scripts. Lots of QA testing was needed to make sure certain combinations of actions didn't blow the heap size (for example, running through a level and killing/destroying only those things that needed to be killed/destroyed to make the level progress). If you do implement your ideas, please let me know how it works out, I would be interested to hear what you thought was good or bad about your approach, and how it might be improved. Cheers, -Paul Laska Hi Markus,

The unsafe method with a heap parameter, sounds similar to what we used in our engine at Savage Entertainment. One of the things we did was to have static sizes defined for the heaps, on a per level/map basis; this has pros and cons, as does everything. ;)

The biggest pro I can remember was that we could tune the heaps to balance for very different memory requirements from level to level, or map to map, depending on the game style. The biggest con was that we were constantly trying to figure out just how small we could get away with making each heap, every time a change was made in the designer’s scripts. Lots of QA testing was needed to make sure certain combinations of actions didn’t blow the heap size (for example, running through a level and killing/destroying only those things that needed to be killed/destroyed to make the level progress).

If you do implement your ideas, please let me know how it works out, I would be interested to hear what you thought was good or bad about your approach, and how it might be improved.

Cheers,
-Paul Laska

]]>
By: Markus Rännare/2011/05/26/ready-set-allocate-part-4/#comment-5202 Markus Rännare Mon, 06 Jun 2011 21:10:04 +0000 Hi Markus, You're welcome. Thank you for the thought you put into such a great question. To be honest, it's not an option I had considered for this series of posts, and probably should have. I haven't run it, but my gut feeling is that putting in the simple mutex and grading performance will vary depending on the number of threads attempting to allocate simultaneously, or attempting to allocate after a context switch in which another thread already holds the mutex. Basically I see this as a potential bottleneck for the system. An alternative thought that comes to mind is, large chunks of memory (heaps) could be sequentially allocated to systems during intialization/reset, and those systems could be responsible for dealing with simultaneous access to their memory. While that distributes the problem, it could also isolate the issue to systems in which simultaneous access is a real concern, rather than burden other systems with the issue when they shouldn't be. Probably something to attempt and play with. :) Cheers, -Paul Laska Hi Markus,

You’re welcome. Thank you for the thought you put into such a great question. To be honest, it’s not an option I had considered for this series of posts, and probably should have.

I haven’t run it, but my gut feeling is that putting in the simple mutex and grading performance will vary depending on the number of threads attempting to allocate simultaneously, or attempting to allocate after a context switch in which another thread already holds the mutex. Basically I see this as a potential bottleneck for the system.

An alternative thought that comes to mind is, large chunks of memory (heaps) could be sequentially allocated to systems during intialization/reset, and those systems could be responsible for dealing with simultaneous access to their memory. While that distributes the problem, it could also isolate the issue to systems in which simultaneous access is a real concern, rather than burden other systems with the issue when they shouldn’t be. Probably something to attempt and play with. :)

Cheers,
-Paul Laska

]]>
By: Markus Rännare/2011/05/26/ready-set-allocate-part-4/#comment-5192 Markus Rännare Mon, 06 Jun 2011 18:22:56 +0000 HI Markus, You're correct, it isn't thread safe, though a mutex and critical section defined around malloc and free could resolve that issue. I don't believe a set of semaphores is appropriate here, since multiple threads could still end up attempting to use the same memory if allocating at the same time. My experience with creating thread-safe designs is limited, so maybe you or someone else with more experience could talk about a better way to handle it than just defining the mutex and critical section I suggest (someone could write it as their post, nudge, nudge, wink, wink)? Cheers, -Paul Laska HI Markus,

You’re correct, it isn’t thread safe, though a mutex and critical section defined around malloc and free could resolve that issue. I don’t believe a set of semaphores is appropriate here, since multiple threads could still end up attempting to use the same memory if allocating at the same time.

My experience with creating thread-safe designs is limited, so maybe you or someone else with more experience could talk about a better way to handle it than just defining the mutex and critical section I suggest (someone could write it as their post, nudge, nudge, wink, wink)?

Cheers,
-Paul Laska

]]>
By: Markus Rännare/2011/05/26/ready-set-allocate-part-4/#comment-5173 Markus Rännare Mon, 06 Jun 2011 09:24:26 +0000