Scheduling and Prime Numbers
by Steve Acaster · in Technical Issues · 03/14/2008 (1:51 pm) · 8 replies
In the interests of performance, I expect using Prime Numbers in scheduling causes less clashes per second when schedules are called, especially if many different schedules are running. Thus causing less "bottlenecks" and giving a "wider spread" of processing.
What I'd like to know is people thoughts on whether it is best to use Prime Numbers in milliseconds;
e.g. schedule(1523, thisfunction1); --- call ever 1.523 seconds - using 1523 as the Prime Number
e.g. schedule(1741, thisfunction2); --- call ever 1.783 seconds - using 1741 as the Prime Number
e.g. schedule(1907, thisfunction3); --- call ever 1.907 seconds - using 1907 as the Prime Number
or whether it should be rounded up to centiseconds?
e.g. schedule(1500, thisfunction1); --- call ever 1.5 seconds - using 15 as the Prime Number
e.g. schedule(1700, thisfunction2); --- call ever 1.7 seconds - using 17 as the Prime Number
e.g. schedule(1900, thisfunction3); --- call ever 1.9 seconds - using 19 as the Prime Number
So my real question is: Is there really a difference in processing performance between the 2 methods when many different schedules are running?
Or am I just being pedantic?
What I'd like to know is people thoughts on whether it is best to use Prime Numbers in milliseconds;
e.g. schedule(1523, thisfunction1); --- call ever 1.523 seconds - using 1523 as the Prime Number
e.g. schedule(1741, thisfunction2); --- call ever 1.783 seconds - using 1741 as the Prime Number
e.g. schedule(1907, thisfunction3); --- call ever 1.907 seconds - using 1907 as the Prime Number
or whether it should be rounded up to centiseconds?
e.g. schedule(1500, thisfunction1); --- call ever 1.5 seconds - using 15 as the Prime Number
e.g. schedule(1700, thisfunction2); --- call ever 1.7 seconds - using 17 as the Prime Number
e.g. schedule(1900, thisfunction3); --- call ever 1.9 seconds - using 19 as the Prime Number
So my real question is: Is there really a difference in processing performance between the 2 methods when many different schedules are running?
Or am I just being pedantic?
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
So - to go back to being pedantic - I'll make my schedules multiples of 32
e.g. schedule(1760, thisfunction3); --- call ever 1.76 seconds - using 55 as the multiple of 32
03/14/2008 (2:29 pm)
I wasn't doing anything bizarre - just wondering what differences would make with performance and whether it was important. Thanks for the info.So - to go back to being pedantic - I'll make my schedules multiples of 32
e.g. schedule(1760, thisfunction3); --- call ever 1.76 seconds - using 55 as the multiple of 32
#3
03/15/2008 (9:58 pm)
Honestly, the extra work you're putting in to spread them out comes out in the wash. Firstly, there is the 32ms granularity. Secondly, you're schedules should mean something rather than being arbitrary random numbers. If you want 20 calls per second, use 50ms. It may not even out at 50ms but at least there's a reason for the number. Is there a particular situation where your functions will be scheduled for a length of time that needs to be prime?
#4
I'm a bit of a novice at hardcore programming (scripting single player levels for FPSs is my forte) and so wasn't sure how much to worry about it - though the answer appears to be not to worry about it at all.
Cheers all.
03/16/2008 (10:26 am)
No my schedules don't need to be prime numbers - I just read somewhere (non-Torque related programming - might have been XNA) that using prime numbers can improve performance by limiting the times calls for processing power clash. I'm a bit of a novice at hardcore programming (scripting single player levels for FPSs is my forte) and so wasn't sure how much to worry about it - though the answer appears to be not to worry about it at all.
Cheers all.
#5
This would be in there "premature optimisation is the root of all evil" category :-)
Gary (-;
03/17/2008 (12:37 pm)
I would suggest that you completely don't worry about it. If you're finding down the line that you're getting hitching because you've got so many things scheduled to run at the same time, then you could do something about it then.This would be in there "premature optimisation is the root of all evil" category :-)
Gary (-;
#6
choose the time period which best suits the task at hand, and don't worry about simultaneity.
if you're scheduling Lots and Lots of work on Lots and Lots of events, then perhaps you could worry about, and using relatively prime times could help, but it's definitely one of those things i wouldn't try to fix until it's revealed as a problem.
03/17/2008 (12:44 pm)
I would also advise completely not worrying about it.choose the time period which best suits the task at hand, and don't worry about simultaneity.
if you're scheduling Lots and Lots of work on Lots and Lots of events, then perhaps you could worry about, and using relatively prime times could help, but it's definitely one of those things i wouldn't try to fix until it's revealed as a problem.
#7
two different populations of cicadas in the same region hibernate for a different prime number of years before emerging, thus minimizing collisions with each other and thus minimizing the probability of the entire population being wiped out by a single predator.
www.sciencenews.org/articles/20030621/mathtrek.asp
03/17/2008 (1:21 pm)
Slightly OT, but Cicadas (the insects) have also dealt with this issue of event scheduling and primes.two different populations of cicadas in the same region hibernate for a different prime number of years before emerging, thus minimizing collisions with each other and thus minimizing the probability of the entire population being wiped out by a single predator.
www.sciencenews.org/articles/20030621/mathtrek.asp
#8
Best quote I've heard in a long time!
03/17/2008 (4:08 pm)
Quote:premature optimisation is the root of all evil
Best quote I've heard in a long time!
Torque Owner Gary "ChunkyKs" Briggs
And they'd only need to be relatively prime, not actually prime. Additionally, the timers only tick every TickMs [32 ms], so anything at sub-TickMs accuracy won't work exactly like you think it will. What are you doing in your timers that means more than one of them at the same time so bad? :fear:
Gary (-;