>>[...]
>>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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to