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 10 months ago* (last edited 10 months 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 10 months ago

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

[–] danhab99@programming.dev 9 points 10 months 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 10 months ago (2 children)

nothing about any of those libraries dictates an OO approach.

[–] Buddahriffic@lemmy.world 2 points 10 months ago (1 children)

Unless it's java.

[–] entropicdrift@lemmy.sdf.org 1 points 10 months 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 10 months 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 10 months ago

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