Re: Need some advice on multithreading
Re: Need some advice on multithreading
- Subject: Re: Need some advice on multithreading
- From: WT <email@hidden>
- Date: Tue, 25 Nov 2008 11:38:55 +0100
>>[...]
>>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.
>>
>I'm not sure I understand the NSTimer concern. Surely the rate for
the timer should not change that frequently. A user can only provide
their commands so quickly (or at worst, you could respond to them only
so quickly...even if the user can provide a new timer interval every 1
ms, surely it would be fine to update the actual timer interval only
every 100 ms or so...the user would never know the difference).
>
>It is unfortunate that NSTimer doesn't appear to have a way to
change the auto-repeat interval after creation, but it seems to me
that creation of NSTimer objects should not be an activity the code
would spend much of its time doing anyway.
My concern is not with the *time* spent in allocating NSTimer objects,
but with the *number* of such allocations, given that the simulation
is rather memory intensive. Suppose the simulation is being observed
by a user who decides to change the simulation rate back and forth
many times. That may actually be a valid and useful thing to do,
depending on the nature of the simulation (for example, to see
different phenomena at different time-scales coming to the surface and
"taking over"), but may not be feasible if doing so implies allocating
more and more objects in a memory-intensive environment.
>More important to you is probably this information from the timer
docs (http://developer.apple.com/documentation/Cocoa/Conceptual/
Timers/Articles/timerConcepts.html#//apple_ref/doc/uid/20000806-
BAJFBAIH):
>
> Because of the various input sources a typical run loop
> manages, the effective resolution of the time interval
> for a timer is limited to on the order of 50-100 milliseconds.
Yes, I'm aware of that and it poses a problem in certain simulations.
>In other words, the best you can hope for is a timer firing 10 to 20
times per second. This is yet another argument in favor of just
running the simulation as fast as it will go. Doing so provides at
least three benefits:
>
>-- Fewer worries about missing corner-cases in the performance
testing (mentioned in my previous message)
>-- Higher resolution simulation (with NSTimer, your simulation
thread just isn't going to get notified that frequently)
>-- No need to manage _any_ NSTimer objects (so no memory management
overhead for that at all)
As I said, it's not always possible or desirable to run the simulation
as fast as it will go, but your point is well taken nonetheless and I
may in the end drop the idea of driving the simulation with a timer,
for those very reasons.
>If you insist on adjusting the simulation frequency, you may find
that using the NSThread's sleepForTimeInterval: method is more
appropriate. I don't know for sure, but I suspect that method uses
Unix's thread-scheduling mechanism, rather than relying on the
NSRunLoop to manage the notification. That's likely to produce higher-
resolution results.
See, this is the kind of advice I was hoping to get, namely, specific
Cocoa suggestions. Thank you for that.
>As far as memory management goes, I think more interesting is the
question of data objects used for inter-thread communication. One
advantage of foregoing the advice to use immutable objects is the
potential for reuse if you use mutable objects. I wouldn't bother
trying to make that optimization unless I found that my code was
performing poorly due to memory management overhead, but if you _do_
find that, it might be worth your while to use a sort of "inter-
thread communication object pool", so that you only have to allocate a
few such objects and reuse them as needed.
Yes, that optimization occurred to me as well and, as you pointed out,
it's something to be done only if needed.
>Still, as with the NSTimer, assuming code of any complexity, it
seems likely that the cost of the other main components -- simulation
and rendering -- will dwarf any overhead due to object maintenance or
memory management. If it doesn't, then there may just be a simply
design problem with the way objects are used and management in the code.
That is true, but it's always that very last byte needing allocation
and not getting it that raises a low-memory exception. :)
Anyway, I thank you (and everyone else who responded) for all the
input and I hope people didn't feel insulted by my objections.
Wagner
PS. Feel free to ignore the remainder of this post since it's not
directly related to Cocoa.
>>>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.
>It's your program, your prerogative. :) Still...
My disagreement is not with your statement that load-adjusting sounds
good in theory but is often not in practice. That I agree with. My
disagreement is with your implied statement that adjusting the
simulation rate is motivated by the desire to balance the CPU load. It
is not.
>>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.
>Sure, they do. The only reason to not run the simulation at the
minimum time-interval possible is to adjust CPU usage. My advice: just
always run the simulation at the minimum time-interval possible.
Actually, they do not. As I pointed out before, these kinds of
problems are typical of numerical integration of differential
equations and have to do with the finite precision of floating point
arithmetic on the computational model employed by our computers. Even
if you had an infinitely powerful CPU, meaning that load-balancing
would not be an issue, you would still suffer from some of these
difficulties. Try to compute the value of a Bessel function using a
recursive relation or, simpler still, try to integrate simple
Newtonian equations of motion using the naive Euler method and you'll
see what I mean.
Also, adjusting CPU use is not the only reason not to run the
simulation at the minimum time-interval possible. Often times, a
simulation will have a region in time where no progress is made for a
long while (a plateau, if you will). In those cases, you want to
increase your time step because it's safe (precision-wise) and
expedient to do so. Otherwise, you'd wait forever for your results.
Moreover, many physical simulations involve more than one time-scale
and it's important to integrate your equations using a time-step that
matches the time-scale of the more interesting phenomena you're trying
to study.
Granted, many of these complications do not arise in the simple
bouncing balls problem, but that's not the point.
>You seem to have misunderstood my statement to mean that you should
_reduce_ the precision always. I'm not saying that. I'm saying that
you should run the simulation at maximum precision always.
And I just explained that always running the simulation at the minimum
time-step is not always possible in practice nor is it always
desirable. Also, note that minimum time-step is not always equivalent
to highest-precision.
>And while I appreciate that you feel I and others have gone off-road
a bit with your question, the fact is, you posted the original
message, and it doesn't make sense for you to then expect people to
ignore aspects of the message you wrote.
I expected (and still do) that people will stick to the subject matter
of this forum. My original post was very clear in regards to what I
needed help with (multithreading in Cocoa) and I also made it clear
that the bouncing balls were being used merely to provide context.
This is not a forum for discussing how to implement physical
simulations, but a forum on Cocoa.
Having said that, I'll admit being guilty of the same sin as I have
just above elaborated on a subject that is unrelated to Cocoa.
>You probably should have made the original message more concise and
to the point, but given that you didn't, objecting to comments offered
by people to parts you never intended for people to care about doesn't
make sense. You posted the message; live with the replies. At worst,
you can just ignore them.
Often times in this forum, people ask questions that are vague at best
and those responding end up requesting details of what the poster is
trying to do. My original message was very clear and, I think, rather
concise, while still providing details of the nature of what I am
trying to do (although using a simplified problem). It should have
been obvious to anyone in this forum that my questions had to do with
Cocoa threads and not with the ins and outs of the math and physics of
bouncing balls.
As for ignoring messages, I can only do so after reading them (unless
warned ahead of time), by which time the time reading them has already
been spent. Just as other people, I prefer not to waste time sifting
through information that's not relevant to what I need.
_______________________________________________
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