Sign in to follow this  
Nick of ZA

Unity SDL cross-platform: processor time and multithreading

Recommended Posts

Nick of ZA    177
Given that I'm currently using SDL for my game, and I made that choice because I wanted it to be cross-platform, I've now started having some misgivings about potential difficulties in actually making it so.

The thing is, I realise that I probably have to code for the lowest common denominator I intend to support. Ultimately, I was hoping to develop on my laptop, a Core2 Duo machine, optimise as much as possible, and later do further development on a "weaker" device to bring it to an even better efficiency. The gameplay of the game is more important, however, than sticking to some lowest common denominator in terms of system specs, so I'd be flexible on this.

Then of course there is the issue of, if I go multithreaded (and that is a very distinct possibility as I will be doing a lot of procedural generation on the fly as the world progresses -- since I desire a seamless world), what can I [i]actually rely on [/i]in terms of what the lowest common denominator provides? I read a post over at the Unity forums where people were saying 2 cores is very common these days, and elsewhere I've read in the past that one thread per core is a good idea, no more (obviously that ignores OS needs but I know little enough about that).

Has anyone faced these challenges (primarily: developing multithreaded for devices with vastly different specs), who would be willing to offer some advice?

Thanks in advance,

Nick

Share this post


Link to post
Share on other sites
Ashaman73    13715
[quote name='Nick of ZA' timestamp='1312966987' post='4847084']
Has anyone faced these challenges (primarily: developing multithreaded for devices with vastly different specs), who would be willing to offer some advice?
[/quote]
Many modern engines gone multithreaded these days. Some papers talk about what approaches are take to support multithreaded game (google for "id tech5 challanges" for an example) . In short, use only few OS threads, avoid OS-locking as much as possible and build your components to support isolated, or atleast "read-only", processing of shared data.

Locking functionality offered by the OS is often very slow and abusing these too much could kill performance. A simple solution is to use synchronisation points, where only the "main" thread gathers and distributes tasks to i.e. job lists which are mostly isolated from each other and could be processed by a single thread.

Double buffering is an other simple,"lockless", synchronisation technique. One thread writes only to one buffer (i.e. waypoint calculation) and this buffer will be swapped next frame by the main thread only (avoiding any data locking at all).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this