Oh wow, a programming language that is not supposed to be used for every single software in the world. Unlike Javascript for example which should absolutely be used for making everything (horrible). Nodejs was a mistake.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
all programs are single threaded unless otherwise specified.
I initially read this as “all programmers are single-threaded” and thought to myself, “yeah, that tracks”
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.
Does Python have the ability to specify loops that should be executed in parallel, as e.g. Matlab uses parfor
instead of for
?
python has way too many ways to do that. asyncio
, future
, thread
, multiprocessing
...
Of the ways you listed the only one that will actually take advantage of a multi core CPU is multiprocessing
yup, that's true. most meaningful tasks are io-bound so "parallel" basically qualifies as "whatever allows multiple threads of execution to keep going". if you're doing numbercrunching in pythen without a proper library like pandas, that can parallelize your calculations, you're doing it wrong.
I’ve used multiprocessing to squeeze more performance out of numpy and scipy. But yeah, resorting to multiprocessing is a sign that you should be dropping into something like Rust or a C variant.
Most numpy array functions already utilize multiple cores, because they're optimized and written in C
I've always hated object oriented multi threading. Goroutines (green threads) are just the best way 90% of the time. If I need to control where threads go I'll write it in rust.
Are you still using matlab? Why? Seriously
No, I'm not at university anymore.
Good for you
Poor prof
We weren't doing any ressource extensive computations with Matlab, mainly just for teaching FEM, as we've had an extensive collection of scripts for that purpose, and pre- and some post processing.
I was telling a colleague about how my department started using Rust for some parts of our projects lately. (normally Python was good enough for almost everything but we wanted to try it out)
They asked me why we're not using MATLAB. They were not joking. So, I can at least tell you their reasoning. It was their first programming language in university, it's safer and faster than Python, and it's quite challenging to use.
"Just use MATLAB" - Someone with a kind heart who has never deployed anything to anything
I tough this was about excel and was like yeah haha!
But is about Python, so I'm officially offended.
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?
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.
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.
let's be honest here, he actually means 0.01 core performance
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!
It only took us how many years?
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 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
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