3 ms·

Multithreading, why does everyone always do it wrong? One of life's big questions.

worldsavior 3y ago
Because there are no actual good sources to implement async/multi threading programs.
rklaehn 3y ago
I think rust does it right in many cases. Raw rust multithreading is a pleasure to use, and some libraries like rayon are extremely unobtrusive. That is why I am somewhat unhappy with the state of async rust. It does not yet have the quality and unobtrusiveness of sync rust libraries like rayon.
- buildbot 3y ago
  Yeah, I just recently picked up rust and rayon is so awesome. It is great to be able to instantly parallelize an iterator.
junon 3y ago
Pray tell, what's the objective right way?
- monsieurbanana 3y ago
  He's saying nobody has found it yet
- darthrupert 3y ago
  99% of the cases: don't. 1%: very carefully.
Thoeu388 3y ago
Redis nailed multithreading :)
chrismsimpson 3y ago
[flagged]
samsquire 3y ago
CPU cycles are practically free but memory latency and synchronization are not. (Hardware threads gives more CPU cycles capacity). People's scalability problems are memory related, not CPU cycles. In other words, we can't scale updating a single memory location with more hardware threads. People often want to scale the updating of something so they add threads, but the contention of memory synchronization prevents that. Scaling independent memory updates works well and is embarrassingly/pleasingly parallel. I am working on a multithreaded design that is scalable and easier. The idea is that if you represent your problem, data flow and control flow as a tree where branches do not communicate, you can get the purported scalability of multiple hardware threads.
- mgaunard 3y ago
  You realize people have been doing those things since the 70s?
  - samsquire 3y ago
    Yes. The state of the art technology has not percolated everywhere. Google's tech stays locked up in Google. Parallelism in many languages that are mainstream is difficult to get right and error prone. I don't think most developers should be working with low level threads or synchronization primitives for business purposes. I am working on a notation and runtime and I'm thinking of automatic parallelisation. There is also Go and Erlang but this is an area I am interested in enough to have an attempt myself. Multithreading can be difficult and I recommend this blog post: https://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html https://bholley.net/blog/2015/must-be-this-tall-to-write-mul... (Check my comments on HN and my profile for more details)
    - mgaunard 3y ago
      Google is not the 70s, and they haven't really done much, and not recently. Google's big thing in that area maybe was MapReduce, which was quite behind the state of the art when they first introduced it. I believe they eventually moved to BSP, which is more in line with what academia have been developing since the early 90s, but that's not really proprietary stuff. But in any case, if you're just talking about scheduling graphs of tasks, there are thousands of competing libraries that do it. https://en.wikipedia.org/wiki/Algorithmic_skeleton https://en.wikipedia.org/wiki/Algorithmic_skeleton Just go to the frameworks and libraries section.

Because there are no actual good sources to implement async/multi threading programs.

I think rust does it right in many cases. Raw rust multithreading is a pleasure to use, and some libraries like rayon are extremely unobtrusive. That is why I am somewhat unhappy with the state of async rust. It does not yet have the quality and unobtrusiveness of sync rust libraries like rayon.

buildbot 3y ago
Yeah, I just recently picked up rust and rayon is so awesome. It is great to be able to instantly parallelize an iterator.

junon 3y ago

Pray tell, what's the objective right way?

monsieurbanana 3y ago
He's saying nobody has found it yet
darthrupert 3y ago
99% of the cases: don't. 1%: very carefully.

Thoeu388 3y ago

Redis nailed multithreading :)

chrismsimpson 3y ago

[flagged]

samsquire 3y ago

CPU cycles are practically free but memory latency and synchronization are not. (Hardware threads gives more CPU cycles capacity). People's scalability problems are memory related, not CPU cycles. In other words, we can't scale updating a single memory location with more hardware threads. People often want to scale the updating of something so they add threads, but the contention of memory synchronization prevents that. Scaling independent memory updates works well and is embarrassingly/pleasingly parallel. I am working on a multithreaded design that is scalable and easier. The idea is that if you represent your problem, data flow and control flow as a tree where branches do not communicate, you can get the purported scalability of multiple hardware threads.

mgaunard 3y ago
You realize people have been doing those things since the 70s?
- samsquire 3y ago
  Yes. The state of the art technology has not percolated everywhere. Google's tech stays locked up in Google. Parallelism in many languages that are mainstream is difficult to get right and error prone. I don't think most developers should be working with low level threads or synchronization primitives for business purposes. I am working on a notation and runtime and I'm thinking of automatic parallelisation. There is also Go and Erlang but this is an area I am interested in enough to have an attempt myself. Multithreading can be difficult and I recommend this blog post: https://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html https://bholley.net/blog/2015/must-be-this-tall-to-write-mul... (Check my comments on HN and my profile for more details)
  - mgaunard 3y ago
    Google is not the 70s, and they haven't really done much, and not recently. Google's big thing in that area maybe was MapReduce, which was quite behind the state of the art when they first introduced it. I believe they eventually moved to BSP, which is more in line with what academia have been developing since the early 90s, but that's not really proprietary stuff. But in any case, if you're just talking about scheduling graphs of tasks, there are thousands of competing libraries that do it. https://en.wikipedia.org/wiki/Algorithmic_skeleton https://en.wikipedia.org/wiki/Algorithmic_skeleton Just go to the frameworks and libraries section.