@sir what about hyperthreading? Does that breach the "no threads" rule?

@nergal it gets more complicated when you start talking about kernels and hardware. The answer is still "no", but with more caveats.

@sir Link to footnote 4 seems to return an error 404

@sir should have expected the site to be in a public repository. just saw it and sent a fix

@sir I feel as though at least some of QEMUs use of threads in justified. I'm less certain of our use of coroutines 😉

@sir You should link all these pages using vanity domains on another page for ease of reference, like the git send-email and git rebase one.

@sir "Share by communicating, not communicate by sharing."

@sir It could maybe even be worth mentioning that shared memory is a thing, so you don't even need to give up performance if you're doing something like image processing where there's a ton of shared state - just explicitly put that state in shm.

The advantage of threads though is cross platform support (Windows can't multiprocess) and that a multiprocessing event loop system is way more code than `#pragma omp parallel for`.

@sir Case in point: swaylock-effects uses threads, and I maintain that the advantage of getting a 4x speedup of a CPU bound task by adding a single pragma is worth it: github.com/mortie/swaylock-eff

@mort @sir This is really a kind of complicated point that the actual goal is to have easy-to-reason-about threading. Truly shared memory *is* indeed great for performance, but throws you into reasonably handling memory safety and locks. There are cases where it *is* truly appropriate, and this may be one, but I've *generally* found that SIMD is better in those situations when available.

@mort @sir And using a language like Clojure or Erlang where concurrent memory access is safe because it's abstracted also gets extremely complicated. And even *there*, it's worth noting that Erlang, the super-parallel language, was actually single core until pretty late in the 2000s or early 2010s.

@mort @sir what do you mean windows can't multiprocess?

@Stella There are two things: One, Windows doesn't have a fork() syscall; you must launch a program from a file, which makes multiprocessing less convenient. Two, launching a new process on Windows is RIDICULOUSLY slow: bitsnbites.eu/benchmarking-os-

I also don't know how Windows' inter-process communication is, but I'd be willing to bet it's not as nice as unix pipes.

@sir A lot of application use multithreading where coroutines would be enough and make the execution non-deterministic for no good reason. Yet, unfortunately, there are CPU bound tasks where the cost of spawning processes and doing messaging is too high and that makes threads useful. I blame languages for not abstracting the concurrency problem better.

@sir You seem to do that a lot, what with useplaintext.email and git-send-email.io. What's the reasoning for spreading stuff across many domains?

@0shame they're cheap and memorable ¯\_(ツ)_/¯

@sir Awesome! now everytime i use the "threading" module on python i will remember your site, i may end up not using threads and link the domain at the top as a reason of it.

@peexea thanks, I just ran out of toilet paper, I'll print this out

@sir

1. what a good reason to buy a domain! :-)

2. I thought it was about "threads" in the Fediverse/Mastodon (spoiler: it's not)

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!