4 ms·

> and that's the problem Intel is facing. It's just a matter of time when developers will make use of higher core numbers, and distributing the workload across

by tomxor 6y ago

> and that's the problem Intel is facing. It's just a matter of time when developers will make use of higher core numbers, and distributing the workload across more cores will also reduce the power consumption of the CPU, which is essential for light and portable laptops. I'm not convinced, parallelism is not inevitable for individual applications, it can be hard or not applicable. I understand there are certain CPU intensive programs where the benefit is too great to ignore, but for the rest it still seems like it's not worth the developers time.

auggierose 6y ago
I can't wait for hardware to have thousands of cores by default. In a way, if you program for iOS, that's already the case if you can target Apple Metal with your problem successfully. Many-cores is certainly worth developer's time. It's just that many developers just don't have the education to make use of it. And software development itself is not good enough right now to make consistent and easy use of it.
- 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 ago
    I 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 ago
      Politics 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 ago
    Which 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.
TinkersW 6y ago
This isn't 2010, using multiple cores is standard practice outside of mindless stuff like webdev.
- aceofspades19 6y ago
  What makes you think web dev is mindless or cannot benefit from multiple cores?

by tomxor 6y ago

auggierose 6y ago

I can't wait for hardware to have thousands of cores by default. In a way, if you program for iOS, that's already the case if you can target Apple Metal with your problem successfully. Many-cores is certainly worth developer's time. It's just that many developers just don't have the education to make use of it. And software development itself is not good enough right now to make consistent and easy use of it.

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 ago
  I 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 ago
    Politics 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 ago
  Which 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.

TinkersW 6y ago

This isn't 2010, using multiple cores is standard practice outside of mindless stuff like webdev.

aceofspades19 6y ago
What makes you think web dev is mindless or cannot benefit from multiple cores?