Re: Need some advice on multithreading
Re: Need some advice on multithreading
- Subject: Re: Need some advice on multithreading
- From: WT <email@hidden>
- Date: Mon, 24 Nov 2008 11:35:42 +0100
Hi Peter,
thanks for answering my post.
>> [...]
>>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.
I'm afraid I'll have to disagree. My concern is not balancing the CPU
load, but getting accurate results. To use the bouncing balls example
again, if the balls move fast enough and if I don't compensate by
decreasing the time-interval through which I'm advancing the motion,
the balls WILL overlap and may do so considerably. Even if they don't
overlap in a way that's visible to the human eye, overlaps may cause
other anomalies, such as energy non-conservation. These kinds of
problems are typical of numerical integration of differential
equations and have nothing to do with optimizing the CPU use.
>[...]
>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. :)
How well I know... :)
>>[...]
>>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.
Very true. Another of my concerns, though, is that having high enough
simulation refresh rates and frame update rates will cause a large
number of object allocations, which will compete with other resources
needed for the simulation to happen. It seems to me that lots of
objects in Cocoa cannot be reused once created and have to be created
again. For instance, as far as I know, there is no way to change the
period of an NSTimer that's already in existence. Since both the
simulation update rate and the frame update rate are timer-driven and
dynamically changeable by the user, I expect lots of NSTimer objects
to be created.
>[...]
>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.
>[...]
Precisely!
>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.
Very true, and it's certainly the case in my application.
_______________________________________________
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