Dyanrec Update #2

Posted on 03 Jul 2011

Right,

So here’s what I got done:

What I’m currently working on is making it so you can have more than one instance of dynarec in a project (it’s pretty sloppy right now, almost everything is coded for one instance only). Adding more emitter functions (finally) and starting on making exec blocks reusable. While in the future dynarec will be able to recover from not being able to allocate more memory, right now it can’t; I really need to look into that (part of the puzzle is call graphing).

On the memory pool. While it does stop fragmentation, it does it at a price. When inserting new nodes a call to mp_alloc is made this is very slow, O(N) slow. So I need to come up with a faster way of managing available blocks. If I wasn’t trying to keep memory usage to a minimum (see below), I’d just make an array of some sort with unused block pointers; but because I’m not I need to come up with a better way.

Memory usage in general is getting a bit steep, for 10001 (weird number right?) code lookup entries and everything that goes along with it (minus the actual memory for execution blocks) it comes to 368,600 bytes (that’s with memory tracking compiled in). If memory tracking wasn’t used that figure would drop (not really by much). With the current and only example there are 160 calls to malloc (well dynarec_allocator) so you’d shave off 640 bytes. This is cause 32 bits is added to any call to dynarec_allocator as way of storing the size of the memory block (for tracking).

One thing I could do is rework the rb tree and get rid of the parent pointer, but I’d need to run tests to see what kind of performance hit I’d take for it. On a side note - I’m loving the red-black tree (it’s so fast!).

What a delicate line we walk… (shoot me now ;))

Peace. Out.

comments powered by Disqus