@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: https://github.com/mortie/swaylock-effects/blob/master/effects.c#L198
@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.
@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: https://www.bitsnbites.eu/benchmarking-os-primitives/
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.
I just put page from #rustbook here:
@peexea thanks, I just ran out of toilet paper, I'll print this out
@sir I wholeheartedly agree.
@sir Thats why I use php. It can't do threads.
1. what a good reason to buy a domain! :-)
2. I thought it was about "threads" in the Fediverse/Mastodon (spoiler: it's not)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!