Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Adventures in concurrent space! Part 2

Sign in to follow this  


Having added a updates per second counter to my app I could finally see how it was performing and I noticed that while I was aiming for 50 updates per second I was infact hanging around 45->48 alot of the time and was getting a tiny amount of stuttering every now and then.

So, a better system was needed, so I decided to look into using boost::thread::sleep() to sleep for a set amount of time instead of just yeilding and seeing if the correct amount of time has passed.

However, boost::thread::sleep() doesnt take an amount of time to sleep for, it takes a time to sleep until using a platform independant boost::xtime type varible. So off to google I go and discover this wonderfull bit of code in the spirit library (also in boost) which lets you sleep for a given amount of milliseconds;

static void
milli_sleep(unsigned long milliseconds)
static long const nanoseconds_per_second = 1000L*1000L*1000L;
boost::xtime xt;
boost::xtime_get(&xt, boost::TIME_UTC);
while (xt.nsec > nanoseconds_per_second)
xt.nsec -= nanoseconds_per_second;


So, I made a quick change to my update loop, removing the check for the time passing and changing boost::yeild() for milli_sleep(10) as 10ms was how long I was using as a time delta. Recompiled and ran it and got a SOILD 25 updates per second out of it, infact it only varied above very slightly. Changing the time from 10 to 5 resulted in a soild 50 updates per second.

To say I'm impressed is an understatement, I need to find a way of stressing the system to see if that holds, but right now I'm pretty impressed and happy that I've got a slightly more stable update speed.

I do need to perform a check on the times its throwing out however, just to make sure they are the correct time apart, however the maths says they should be so I dont expect any problems with it [grin]

While it does appear to do 50 updates per second the sleep method drifts off the tick and introducing a loop to correct it seems to slow things down to 25 updates per second, which isnt overly usefull. As such I've reverted back to my orignal loop, however a change in my state swapping code appears to have removed and jitters (it checks to make sure the next update is newer than the current, if it isnt it doesnt swap and the linear interpolation appears to turn into extrapolation, which appears to work well for my rotating cubes, I dont know how it will react in a real world situation however.
Sign in to follow this  


Recommended Comments

There are no comments to display.

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!