{"id":30813,"date":"2020-11-25T16:58:08","date_gmt":"2020-11-25T21:58:08","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30813"},"modified":"2020-12-24T13:20:08","modified_gmt":"2020-12-24T18:20:08","slug":"libdispatchs-unmet-promise","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/11\/25\/libdispatchs-unmet-promise\/","title":{"rendered":"libdispatch’s Unmet Promise"},"content":{"rendered":"

Thomas Clement<\/a>:<\/p>\n

Apple demonstrated the libdispatch and the promise seemed great, they introduced the notion of serial queues and told us that we should stop thinking in term of threads and start thinking in term of queues. We would submit various program tasks to be executed serially or concurrently and the libdispatch would do the rest, automatically scaling based on the available hardware. Queues were cheap, we could have a lot of them. I actually remember very vividly a Q&A at the end of one of the WWDC sessions, a developer got to the mic and asked how many queues we could have in a program, how cheap were they really? The Apple engineer on stage answered that most of the queue size was basically the debug label that the developer would pass to it at creation time. We could have thousands of them without a problem.<\/p>\n

[…]<\/p>\n

Then the problems started. We ran into thread explosion which was really surprising because we were told that the libdispatch would automatically scale based on the available hardware so we expected the number of threads to more or less match the number of cores in the machine. A younger me in 2010 asked<\/a> for help on the libdispatch mailing-list and the response from Apple at the time was to remove synchronization points<\/a> and go async all the way<\/a>.<\/p>\n

As we went down that rabbit hole, things got progressively worse. Async functions have the bad habit of contaminating other functions: because a function can’t call another async function and return a result without being async itself, entire chain calls had to be turned async.<\/p>\n

[…]<\/p>\n

Turns out Apple engineers are developers just like us and met the exact same problems that we did. […] An Apple engineer also revealed<\/a> that a lot of the perf wins in iOS 12 were from daemons going single-threaded.<\/p>\n

[…]<\/p>\n

Now I’m a bit worried because I see all those shiny new things that Apple is planning to add into the Swift language and I wonder what might happen this time.<\/p><\/blockquote>\n\n

Via Peter Steinberger<\/a>:<\/p>\n

\n

Please see past the clickbaity title. It failed to deliver on the promise. It’s still incredibly useful. It’s just dangerous that the documentation wasn’t updated to reflect this.<\/p>\n<\/blockquote>\n\n

Greg Titus<\/a>:<\/p>\n

\n

To call any technology a failure because it was initially over-promised would leave pretty much no successes ever.<\/p>\n

Coding under Dispatch is a lot nicer than pthreads or NSThread<\/code>\/NSLock<\/code>, which were the options on the platform before its debut. By my definition that’d be success.<\/p>\n<\/blockquote>\n\n

Alexis Gallagher<\/a>:<\/p>\n

\n

P1. Task queues will be easier than threads & locks.<\/p>\n

P2. libdispatch can handle many queues and<\/em> it is sensible to organize a program that way.<\/p>\n

Could be we agree that P1 was true but P2 proved false for a mix of performance and programming model complexity reasons.<\/p>\n<\/blockquote>\n\n

Jonathan Grynspan<\/a>:<\/p>\n

\n

I say: dispatch long-running (like, seconds or more) tasks off the UI thread, including as much I\/O as possible. Everything else can run on one thread. Other processes can use other cores. Enforce in API by making most stuff sync but long tasks async with a completion handler.<\/p>\n<\/blockquote>\n\n

David Smith<\/a>:<\/p>\n

\n

Personally I currently prefer a small number of queues (or workloops!) for execution contexts and unfair locks for protecting state. For example cfprefsd uses*<\/a> a two queue model (“request processing” and “async IO” queues), but fine grained locking.<\/p>\n<\/blockquote>\n\n

Marcel<\/a> Weiher<\/a> (quoting his excellent iOS and macOS Performance Tuning<\/a>):<\/p>\n\n

\n

Due to the pretty amazing single-core performance of today’s CPUs, it turns out that the vast majority of CPU performance problems are not, in fact, due to limits of the CPU, but rather due to sub-optimal program organization<\/p>\n<\/blockquote>\n\n

\n

In the end, I’ve rarely had to use multi-threading for speeding up a CPU-bound task in anger, and chances are good that I would have made my code slower rather than faster. The advice to never optimize without measuring as you go along goes double for multi-threading.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n