Threading ORX

edited December 2009 in Projects - Tools

Currently working on an attempt to thread orx to improve efficiency. So far we have had no success - are there any suggestions on what code blocks could be threaded to improve performance?

Tyler Matt and Jon


  • edited December 2009
    Hi and welcome here to all of you,

    I was thinking about threading a couple of weeks ago as I wanted to implement threading based on the clock module: groups of clocks would be separated on different threads/cores/CPUs thus spreading the update callbacks in an easy way.

    The tricky part would then be to separate the right tasks while keeping scheduler consistency.

    However that still leaves concurrent access issues. Most of datas are module-centric and are only accessed inside the module (FXs, sounds, ...). However stuff like animations or physics data are accessed from the object module that centralizes object parts updates.

    I don't have any easy guidelines for adding multi-threading in orx, mostly because I need to think more about it.
    If you want to share your current work with me so we can try to figure something out together, please contact me by email or pm.

    Also, if you want performance improvement, one first big step would be to add a partitionner to orx (it's one of the todo) that would greatly speed up things like rendering and object updates.
  • edited December 2009
    Right now we have only threaded some small functions that don't seem to take up much clock time. We also had to remove all the fastcalls they created issues for the threads. We should have some examples of what we have done with pthreads wrapped up by tomorrow.
  • edited December 2009
    Issues with the fastcall? Ah well, weird.

    The easy way to remove the fastcalls is to change its definition in orxDecl.h (as it's done for 64bit versions for example) but I presume that's what you did anyway.
  • edited January 2010
    After giving some additional thoughts to this question, if we consider the 3 ways of adding multithreading support as described in this article, the first solution (synchronous function) is pretty easy to implement given orx's architecture (clock module, again).
    That's also the model I'm the most familiar with in my professional life.

    The asynchronous function model would be tricky to implement.

    As for the data parallel model, some parts of orx (animation, FX, spawners, ...) look like they're the perfect candidates for this.

    My guess is that a mix between the synchronous function and the parallel data models can be achieved with orx without too much of a trouble.
    It'd still require some non-trivial changes such as using buckets to group objects based on their frame hierarchy, so I can't say it's a 1-day work.
    There's still the problem of scaling depending on the hardware architecture so as to get as most benefits as possible with this mixed approach, but I don't think it'd be too hard either.

    I'll think about it more in the coming days. For now I have a hungry and crying baby that doesn't want me to think more about it! ;)
  • edited January 2010
    Hi oitORX,

    In the latest release (v1.1 released today), the game loop has been modified and should now adapt pretty well to the data parallel model.

    All the updates called through orxObject_UpdateAll() (ie. the callbacks registered by each structure in the call to orxStructure_Register()) are independent for objects that are not linked in a parent/child way.

    So basically, building the buckets should be made knowing the number of wanted threads (based on the number of available cores) and knowing the object-frame hierarchy. Every object which parent is the root frame is independent from any other object as long as it doesn't have any children. So as to make this detection easier, it would be probably a good thing to store the owner in the frames (as frames can be owned by other structures than objects).

    I'm currently focused on the iPhone port of orx, but when I'm done in a couple of weeks (hopefully), I'll be happy to help with multi-threading orx if you're interested. This first approach to multi-threading should not be too complex to implement and will allow to parallelize tasks such as animation, spawners, FX and sound updates without having to worry about concurrent accesses.
Sign In or Register to comment.