4 ms·

People have been saying this 20ish years ago (or probably much longer) - more, simple cores are the future. In my experience, people just don't know how to bui

People have been saying this 20ish years ago (or probably much longer) - more, simple cores are the future. In my experience, people just don't know how to build multi-threaded software and programming languages haven't done all that much to support the paradigm. Multi threading is still the domain of gnarly bugs, and specialists writing specialist software. The only kind of forward looking thing I've seen in this area is the Bend language that has been making strides a couple months ago. And besides all that, Amdahl's law still exists - if 10% of the program cannot be parallelized, you're going to get a 10x speedup at most. Every consumer grade chip tends to have that many cores already.

DrBazza 2y ago
> In my experience, people just don't know how to build multi-threaded software and programming languages haven't done all that much to support the paradigm. Go? Rust? Any functional language?
- hulitu 2y ago
  Writing multithreaded programs does not means that people know how to do this. Just fire up the Windows Process Explorer and look at the CPU graphs.
- torginus 2y ago
  Go just turned a bunch of library constructs (green threads, queues) into language keywords, many languages have the same stuff with a bit more involved syntax. Rust in my opinion, is the biggest admission of failure of modern multithreaded thinking, with having classes like 'X but single threaded' and 'X but slower but works with multiple threads', requiring a complex rewrite for the code to even compile. It's moving all the mental burden of threading to the programmer. CPUs have the ability to automatically execute non-dependent instructions in parallel, at the finest granularity. Yet if we take a look at a higher level, on the level of functions, and operational blocks of a program, there's almost nothing production grade that can say: Hey, you sort array A and B and then compare them, so lets run these 2 sorts in parallel.
hulitu 2y ago
> Multi threading is still the domain of gnarly bugs, and specialists writing specialist software. It is not even there. Windows (7,10) has difficulties splitting jobs between I/O and processor. Simulations take hours because of this and because Windows like to migrate tasks from one core to the others.
- torginus 2y ago
  I haven't written low-level code for Windows for a while, but I recall that all Windows I/O since the NT days has been asynchronous at the kernel level. An I/O thread is purely an user-space construct. In Linux, I/O threads are real, with true asynchronous I/O only being recently introduced with io_uring.
Pet_Ant 2y ago
> Multi threading is still the domain of gnarly bugs, and specialists writing specialist software. 1) In the cloud there are always more requests to serve. Each request can still be serial. 2) Stuff like reactive streams allow for parallelisation. The independent threads acquiring locks will forever be difficult, but there are other models that are easier and getting adopted.

DrBazza 2y ago

> In my experience, people just don't know how to build multi-threaded software and programming languages haven't done all that much to support the paradigm. Go? Rust? Any functional language?

hulitu 2y ago
Writing multithreaded programs does not means that people know how to do this. Just fire up the Windows Process Explorer and look at the CPU graphs.
torginus 2y ago
Go just turned a bunch of library constructs (green threads, queues) into language keywords, many languages have the same stuff with a bit more involved syntax. Rust in my opinion, is the biggest admission of failure of modern multithreaded thinking, with having classes like 'X but single threaded' and 'X but slower but works with multiple threads', requiring a complex rewrite for the code to even compile. It's moving all the mental burden of threading to the programmer. CPUs have the ability to automatically execute non-dependent instructions in parallel, at the finest granularity. Yet if we take a look at a higher level, on the level of functions, and operational blocks of a program, there's almost nothing production grade that can say: Hey, you sort array A and B and then compare them, so lets run these 2 sorts in parallel.

hulitu 2y ago

> Multi threading is still the domain of gnarly bugs, and specialists writing specialist software. It is not even there. Windows (7,10) has difficulties splitting jobs between I/O and processor. Simulations take hours because of this and because Windows like to migrate tasks from one core to the others.

torginus 2y ago
I haven't written low-level code for Windows for a while, but I recall that all Windows I/O since the NT days has been asynchronous at the kernel level. An I/O thread is purely an user-space construct. In Linux, I/O threads are real, with true asynchronous I/O only being recently introduced with io_uring.

Pet_Ant 2y ago

> Multi threading is still the domain of gnarly bugs, and specialists writing specialist software. 1) In the cloud there are always more requests to serve. Each request can still be serial. 2) Stuff like reactive streams allow for parallelisation. The independent threads acquiring locks will forever be difficult, but there are other models that are easier and getting adopted.