Re: Need some advice on multithreading
Re: Need some advice on multithreading
- Subject: Re: Need some advice on multithreading
- From: Peter Duniho <email@hidden>
- Date: Mon, 24 Nov 2008 00:41:45 -0800
Mike already gave a bunch of good advice, so I'll just try to
usefully expand on that (but I also have one "sort-of" disagreement
I'll mention :) )...
Date: Mon, 24 Nov 2008 01:06:17 +0100
From: WT <email@hidden>
[...]
2. continuously running the simulation engine, at a rate that can also
be changed dynamically by the user (for instance, in the bouncing
balls example, increasing gravity makes the balls move faster, thereby
requiring the engine to run more often in order to preserve accuracy
and to prevent anomalies such as the balls overlapping one another);
While it may wind up making sense to put the simulation engine in a
separate thread, I would recommend _not_ trying to adjust the
simulation rate to account for the speed of the balls, precision,
etc. This sort of load-adjusting sounds good in theory, but it
ultimately fails because the performance characteristics of the code
changes according to the settings.
In particular, in this scenario the best you can hope for is to
consume less CPU than the simulation would need at its most precise,
when the balls are moving more slowly. But your code will still need
to perform adequately at the highest ball speed, and you'll
necessarily still have to limit just how fast the updates can go (if
by no other means than that the simulation thread winds up running
full throttle without any delay). If the program can't provide a
good user experience in that situation, then you need to set the
limits lower to where it can, and once you've done that, you gain
very little by reducing the performance load when lower precision is
feasible.
On the other hand, there are some significant risks to trying to
implement something like this, not the least of which is the risk of
getting it wrong. :) The other risk is that some high-load scenario
may miss testing (testers make mistakes too :) ), and it will go
undetected because of that. If you are running the simulation at its
highest possible precision all the time, then you are more likely to
detect performance issues.
[...]
Is this the right idea? Does anyone have a better suggestion? Are
there any pitfalls that I'm not seeing? One concern I have is that
there might be some weird interactions between running the simulation
and drawing the results due to the fact that the simulation engine is
running on a timer and the drawing engine is running on another timer,
and their periods might not be commensurate.
As long as the refresh rate of your simulation is high enough and the
frame rate is high enough, you should not notice any anomalies due to
the differences between the two. You are right that there will be
theoretical unevenness in the rendering, but with everything
happening fast enough, a human isn't going to notice.
I recommend you pay particular attention to Mike's thoughts on
synchronization and data passing, re: immutable objects and messaging
(a form of immutable objects, assuming he means what I think he
means). The less that data actually needs to be synchronized between
threads, the better.
The one disagreement I have with his comments is here (and it's not
so much a disagreement as it is a redirection):
Date: Sun, 23 Nov 2008 20:31:01 -0500
From: "Michael Ash" <email@hidden>
[...]
- When multithreading for the purposes of optimization as you're
doing, treat it as any other optimization. That is, measure and
profile your app before you do anything else to it. Trying to figure
out where to put the threads when you don't even know what parts of
your app are slow is pointless. Just as it's a bunch of wasted effort
to carefully hand-craft a super fast assembly language version of a
function that only runs one time for one millisecond, it's likewise a
bunch of wasted effort to carefully come up with a multithreaded
implementation of such a function. In your case, if the simulation
engine only takes up, say, 10% of your CPU time compared to display,
then the absolute possible best speed gain you could ever see from
shoving it into a background thread would be 10%, probably not worth
all the work and risk.
Mike starts with the constraint "when multithreading for the purposes
of optimization", and taken at face value I don't see anything wrong
with the paragraph per se. But...
There's "optimization", and then there's "optimization". :) I have
the impression from your original message that this isn't so much
about improving throughput as it is about keeping the user-interface
from being dependent on the simulation rate, thus improving the user
experience. In programs where the simulation and/or screen rendering
is very slow, but user-input is handled only between frames, the user
experience can be very frustrating, as compared to a program that is
always ready to respond to the user via a separate thread (OS quantum
is usually something like 50ms, which is generally plenty responsive
for UI).
So, in that case, even if throughput isn't improved much, putting
some work in a separate thread can still "optimize" other aspects of
the way the program works.
Also, not directly related to Mike's comment, but I'll point out that
multithreading can be a _design_ optimization as well. That is,
while it will necessarily introduce some complexities into the
implementation, it can also greatly simplify other aspects, by
allowing the various work in the program to be partitioned more
completely. So, there are often benefits to implementing
multithreaded code, even if performance will not be improved one bit.
Pete
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden