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.

[–] WolfLink@sh.itjust.works 8 points 5 days ago* (last edited 5 days ago) (1 children)

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.

[–] itslilith@lemmy.blahaj.zone 1 points 5 days ago

Most numpy array functions already utilize multiple cores, because they're optimized and written in C

[–] danhab99@programming.dev 9 points 6 days ago (1 children)

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.

[–] lime@feddit.nu 7 points 6 days ago (2 children)

nothing about any of those libraries dictates an OO approach.

[–] Buddahriffic@lemmy.world 2 points 6 days ago (1 children)

Unless it's java.

[–] entropicdrift@lemmy.sdf.org 1 points 5 days ago

Meh, even Java has decent FP paradigm support these days. Just because you can do everything in an OO way in Java doesn't mean you need to.

[–] danhab99@programming.dev 0 points 6 days ago (1 children)

If I have to put a thread object in a variable and call a method on it to start it then it's OO multi threading. I don't want to know when the thread spawns, I don't want to know what code it's running, and I don't want to know when it's done. I just want shit to happen at the same time (90% of the time)

[–] lime@feddit.nu 4 points 5 days ago

the thread library is aping the posix thread interface with python semantics.