Thanduel

Just to start there was a large effort originally to show that memory was a significant issue. This can be seen in the original posts connected with this work and all the profiling posted in that thread. Whilst I do not think that the memory improvement would solve the performance problems related to algorithmic issues I do think it will be more than just a fractional improvement. However, to verify this my plan is to target specific areas that are critical to performance first like the unit ranging code or the pathfinder. I agree that just changing the entire codebase to use a memory pooling system without first verifying that it is helpful would be stupid a lot of work for little benefit. Thanks for the link to paper.

I've created a ticket for this and begun to work on it. So far I've just finished getting to grips with RedFox's code. http://trac.wildfiregames.com/ticket/3362 Hopefully I'll have something useful to report back in a few weeks.

Despite the fact that in the example he uses stack allocation it still serves as a good illustration of the potential performance difference between normal heap allocation and a memory pool. This is because the main function of a memory pool is to return a pre-allocated memory location of a specific size. In the case of the example this performance difference is exaggerated because there is only one pool of memory to return so no logic is required to determine which pool to return but the outcome is still relevant. This is because the source of the memory for the pool is irrelevant ie stack or heap. The point is the machinery required to get memory from a pre allocated source is much faster. In the case of 0ad you would pre-allocate a huge chunk of memory on the heap and divide it into set sizes in the initialisation. During run time the main machinery would be to pass out the next free block of a size that satisfies the memory request. This adds some logic but that logic would never be slower than a search through the heap.

I can't seem to connect to trac or update my svn repository. I can't even open the svn url in my browser.

It can be an order of magnitude faster: http://www.codeproject.com/Articles/27487/Why-to-use-memory-pool-and-how-to-implement-it If it were just a slight improvement it wouldn't be worth it. C++ compilers use a general purpose allocation system that is good enough for most applications. They also provide a mechanism for people to use special purpose allocators. So for example when you instantiate an STL data structure you can pass in a custom allocator for it to use. A memory pool system pre-allocates memory and divides it up into set sized portions that can be very quickly handed out. It allows you to circumvent the long search times for malloc to allocate memory off the heap.

Free cookies on Sundays. And you can achieve much faster and much more stable allocation times for dynamic memory allocation.

Thanks for your response Leper. I had hoped that more work had happened behind the scenes. I think it would be a worthwhile endeavour to use a memory pooling system. It is just a mamoth task to integrate into the codebase and tune it to be the right size for the game. I'm having to work on a pure C memory pool implementation for work, perhaps I can find some overlap and contribute this. We will see.

Hi 0ad Devs! About two years ago there was an attempt at converting 0ad's dynamic memory usage to a memory pool system. Eg ticket #2020 which is closed and marked wontfix. Did anything ever come of this, I know RedFox's mega patch had to be broken up, but as far as I can see little of his code made it into the main 0ad repo. Were there specific technical reasons why this approach was rejected?

Thanks for your quick response, that solves the puzzle.

Hi I'm looking for some info about how the size of certain map obstructions are determined. In the xml files associated with each map there is an entity list. Each entity points to a template. For some of these entity templates there is information about obstruction type and size. However whether a template includes obstruction information or not is fairly random. For example the apple tree template includes an obstruction type and radius but most other trees don't. Is there another place I should look for the size of each obstruction? Does the game use a standard obstruction size for most entities of a certain type for example: do all trees use the same obstruction radius except where otherwise specified?

Speaking of the maths functions, I recently spent some time writing faster algorithms for the fixed point trig functions. The performance improvement is about double for both atan2 and the sincos function with improved accuracy in the case of the atan2 function. Hopefully that is helpful in some way for what you are doing. Here is the ticket: http://trac.wildfiregames.com/ticket/2109 Also I agree with you that it doesn't make sense that methods like Zero and Pi create new objects instead of providing a reference to a predefined const object. Personally I got around that by making the paramaterised constructor public so that I could define static const objects -- for example so that I could define a static const lookup table that is evalulated at compile time.

Porting the game to C# is a terrible idea. Not only will it break linux portability making the game reliant on mono, but it will never be as fast as well written C/C++. The answer to the performance issues is patience and hard work on the code base not magic language fixes. The current fundraiser is a recognition of this.

This seems the relevant place to post this so: I have started working on a few small optimisations for the fixed point library starting with http://trac.wildfiregames.com/ticket/2109 with some more planned as time permits.

Awesome to see progress, even if you are dissappointed with the results it is still a giant leap in the right direction.

Are there any more thoughts on this or does this thread need some benchmarks to move forward? I've seen mention of concern about C++11 leading to dropping support for certain platforms. Using C++11 will make no difference to the end user aside from the free performance improvements, it will not change platform compatibility for the end user. As I've mentioned above all the major compilers support C++11 I'm not sure what older compilers are worth mentioning however as may be seen in the link given above even the intel compiler supports C++11. The only potential restriction would be to use only the features supported by MSVC 2010. The use of Boost makes no difference, using C++11 with Boost will improve Boost's performance. The latest versions of Boost make use of C++11 features conditionally on the compilers support and the C++03 versions will compile with a C++11 compiler.