> I don't like the idea of a multithreaded aproach by default, because as a > general rule, you > should not make your application multithreaded unless you have a good > reason.
a) The reality is that Cocoa already exposes you to a lot of concurrency and asynchronisity, and is only going to do much more so in future. That said, there are limits to what can be done here (especially with dispatch queues; the way GCD paradigms interact with callback patterns is far from seamless). b) This convenientional wisdom is, in my humble opinion, antiquated. It's just the reality today that multi-threaded performance scales better than single-threaded performance. It has been that way for nearly a decade, I'd say. You may disregard that as irrelevant to your app XYZ because any single core today is good enough for it, but just look at the introduction of the iPhone as an example of how single-threaded performance can drop very abruptly, and how you eventually got more cores but not much of a core boost. And aside from performance, there are many other factors such as latency, responsiveness etc that are intertwined with concurrency (in the sense that dispatch queues, background threads, etc target all the issues simultaneously) which make it wise to get away from a serial world view, even if you don't otherwise pro-actively introduce concurrency. I am almost certainly on the edge of the bell curve, having spent many years now working on performance tools and HPC, but I've noticed the curve is catching up to me. To those riding the wave, I can promise you this: parallel programming really isn't that hard. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
