4 ms·
Concurrency, as they say, is a bitch. I would hate to program against that model. The best model I've found so far is cooperative multithreading, that is, coro
by kabdib 6y ago
Concurrency, as they say, is a bitch. I would hate to program against that model.
The best model I've found so far is cooperative multithreading, that is, coroutines that explicitly yield control, combined with well-isolated worker threads and a rendezvous mechanism for passing parameters and getting results back. I can write code all day long in this model and not run into very hard to find concurrency issues . . . or at least, not as many. I've written a ton of code in the "every thread for itself, have fun with locking" universe, and man, life is just too short for that stuff.
Naturally you run out of processor headroom in this model because you're essentially single-threaded; message passing between processes and running multiple services, one in each process, is one good approach to scaling. Often you can scale out to the network, too, and with 1K cores you need start worrying about the blast radius of your services when things eventually go sideways so getting off the box is a good idea. And things will go sideways.
I can see a thousand cores being useful for embarrassingly parallel things, like classic graphics algorithms where you're doing mostly SIMD with a few variations. But I can't imagine wrangling a zillion cores to do "random logic" type applications where you have to use traditional low-level synchronization primitives. See above: life is short.
Feel free to color me a dinosaur. I've only got another 20 years of my career to figure this out :-)
- auggierose 6y agoI mostly agree with you. It doesn't help that software development is so archaic right now. I would like to express just what is necessary for a certain problem, and not address the irrelevant aspects. For example, if I want to express an embarrassingly parallel algorithm, which does something embarrassingly simple, why do I have to drop down to C++11 to get it to run fast on iOS / Apple Metal? Something is needed that is a superset of Mathematica and Isabelle to remove clutter. It is that clutter that makes parallel programming a mess.
- pjmlp 6y agoPolitics mostly, in 2000 no one would believe what JavaScript JITs are capable of, but without the willingness to spend the necessary resources to make it happen, it is hard to prove it is possible. So most people just hand wave one assumptions as day dreaming and they go back their tools as they always did.
- pjmlp 6y agoWhich is why originally WinRT had only asynchronous APIs (and Android as well), because Microsoft and Google both wanted to push developers to do the right thing and not code single threaded UIs. On WinRT with how everything turned out with UWP, now as per Reunion reboot, they are supporting again both models, as that was one of the reasons why many devs did not jumped into UWP app model. On the Android side, they eventually came up with WorkManager and Concurrent. Also for those in the Kotlin train, co-routines. As for what best models, I use to like doing thread based stuff, but came to enjoy using good old processes instead. Security and stability issues haven proven that having the process sandbox, with OS level IPC is a much better way to work with parallel/concurrency programming, and processes must not even run all on the same computer, so one can scale across the cluster as well.