You must log in or register to comment.
all programs are single threaded unless otherwise specified.
It’s safe to assume that any non-trivial program written in Go is multithreaded
And yet: You’ll still be limited to two simultaneous calls to your REST API because the default HTTP client was built in the dumbest way possible.
Really? Huh, TIL. I guess I’ve just never run into a situation where that was the bottleneck.
But it’s still not a guarantee
Definitely not a guarantee, bad devs will still write bad code (and junior devs might want to let their seniors handle concurrency).
I absolutely love how easy multi threading and communication between threads is made in Go. Easily one of the biggest selling points.
Key point: they’re not threads, at least not in the traditional sense. That makes a huge difference under the hood.
Well, they’re userspace threads. That’s still concurrency just like kernel threads.
Also, it still uses kernel threads, just not for every single goroutine.
What I mean is, from the perspective of performance they are very different. In a language like C where (p)threads are kernel threads, creating a new thread is only marginally less expensive than creating a new process (in Linux, not sure about Windows). In comparison creating a new ‘user thread’ in Go is exceedingly cheap. Creating 10s of thousands of goroutines is feasible. Creating 10s of thousands of threads is a problem.
Also, it still uses kernel threads, just not for every single goroutine.
This touches on the other major difference. There is zero connection between the number of goroutines a program spawns and the number of kernel threads it spawns. A program using kernel threads is relying on the kernel’s scheduler which adds a lot of complexity and non-determinism. But a Go program uses the same number of kernel threads (assuming the same hardware and you don’t mess with GOMAXPROCS) regardless of the number of goroutines it uses, and the goroutines are cooperatively scheduled by the runtime instead of preemptively scheduled by the kernel.
Great details! I know the difference personally, but this is a really nice explanation for other readers.
About the last point though: I’m not sure Go always uses the maximum amount of kernel threads it is allowed to use. I read it spawns one on blocking syscalls, but I can’t confirm that. I could imagine it would make sense for it to spawn them lazily and then keep around to lessen the overhead of creating it in case it’s needed later again, but that is speculation.
Edit: I dove a bit deeper. It seems that nowadays it spawns as many kernel threads as CPU cores available plus additional ones for blocking syscalls. https://go.dev/doc/go1.5 https://docs.google.com/document/u/0/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/mobilebasic
I think OP is making a joke about python’s GIL, which makes it so even if you are explicitly multi threading, only one thread is ever running at a time, which can defeat the point in some circumstances.
no, they’re just saying python is slow. even without the GIL python is not multithreaded. thethreadlibrary doesn’t use OS threads so even a free-threaded runtime running “parallel” code is limited to one thread.apparently not!
If what you said were true, wouldn’t it make a lot more sense for OP to be making a joke about how even if the source includes multi threading, all his extra cores are wasted? And make your original comment suggesting a coding issue instead of a language issue pretty misleading?
But what you said is not correct. I just did a dumb little test
import threading import time def task(name): time.sleep(600) t1 = threading.Thread(target=task, args=("1",)) t2 = threading.Thread(target=task, args=("2",)) t3 = threading.Thread(target=task, args=("3",)) t1.start() t2.start() t3.start()And then
ps -efT | grep pythonand sure enough that python process has 4 threads. If you want to be even more certain of it you canstrace -e clone,clone3 python ./threadtest.pyand see that it is makingclone3syscalls.is this stackless?
anyway, that’s interesting! i was under the impression that they eschewed os threads because of the gil. i’ve learned something.
Now do computation in those threads and realize that they all wait on the GIL giving you single core performance on computation and multi threaded performance on io.Correct, which is why before I had said
I think OP is making a joke about python’s GIL, which makes it so even if you are explicitly multi threading, only one thread is ever running at a time, which can defeat the point in some circumstances.
Ups, my attention got trapped by the code and I didn’t properly read the comment.
Isn’t that what threading is? Concurrency always happens on single core. Parallelism is when separate threads are running on different cores. Either way, while the post is meant to be humorous, understanding the difference is what prevents people from picking up the topic. It’s really not difficult. Most reasons to bypass the GIL are IO bound, meaning using threading is perfectly fine. If things ran on multiple cores by default it would be a nightmare with race conditions.
I haven’t heard of that being what threading is, but that threading is about shared resourcing and memory space and not any special relationship with the scheduler.
Per the wiki:
On a multiprocessor or multi-core system, multiple threads can execute in parallel, with every processor or core executing a separate thread simultaneously; on a processor or core with hardware threads, separate software threads can also be executed concurrently by separate hardware threads.
https://en.m.wikipedia.org/wiki/Thread_(computing)
I also think you might be misunderstanding the relationship between concurrency and parallelism; they are not mutually exclusive. Something can be concurrent through parallelism, as the wiki page has (emphasis mine):
Concurrency refers to the ability of a system to execute multiple tasks through simultaneous execution or time-sharing (context switching), sharing resources and managing interactions.
https://en.m.wikipedia.org/wiki/Concurrency_(computer_science)
I initially read this as “all programmers are single-threaded” and thought to myself, “yeah, that tracks”
Oooooh this is really cool, thanks for sharing. How could I install it on Linux (Ubuntu)? I assume I would have to compile CPython. Also, would the source of the programs I run need any modifications?
From memory I can only answer one of those: The way I understand it (and I could be wrong), your programs theoretically should only need modifications if they have a concurrency related bug. The global interlock is designed to take a sledgehammer at “fixing” a concurrency data race. If you have a bug that the GIL fixed, you’ll need to solve that data race using a different control structure once free threading is enabled.
I know it’s kind of a vague answer, but every program that supports true concurrency will do it slightly differently. Your average script with just a few libraries may not benefit, unless a library itself uses threads. Some libraries that use native compiled components may already be able to utilize the full power of you computer even on standard Python builds because threads spawned directly in the native code are less beholden to the GIL (depending on how often they’d need to communicate with native python code)
Thanks for the answer, I really hope Synapse will be able to work with concurrency enabled.
In this case, it’s a feature of the language that enables developers to implement greater amounts of parallelism. So, the developers of the Python-based application will need to refactor to take advantage of it.
don’t worry it’ll use all the RAM anyway
I paid for all the memory. I’ll use all the memory.
JG Memoryworth
No RAM gets wasted!
let’s be honest here, he actually means 0.01 core performance
Yes, 0.99 performance being consumed by the interpreter.
Do you mean Synapse the Matrix server? In my experience, Conduit is much more efficient.
i wish they would switch the reference implementation to conduit
there is core components on the client side in rust so maybe that’s the way for the future
Yep, I mean as in matrix. There is currently no was to migrate to conduit/conduwuit. Btw from what I’ve seen conduwuit is more full-featured.
I may have something to read up on.
The documentation is kinda lacking, but if you could figure out how to set up Synapse then you can probably figure out Conduit too. https://conduit.rs/
I prefer this default. Im sick of having to rein in Numba cores or OpenBlas threads or other out of control software that immediately tries to bottleneck my stack.
CGroups (Docker/LXC) is the obvious solution, but it shouldn’t have to be
I tough this was about excel and was like yeah haha!
But is about Python, so I’m officially offended.
Python
…so… so you made it single threaded?
I’ll be honest, this only matters when running single services that are very expensive. it’s fine if your program can’t be pararlelized if the OS does its job and spreads the love around the cpus
It only took us how many years?
!lemmySilver
