this post was submitted on 14 Oct 2024
18 points (100.0% liked)

Python

6405 readers
2 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

📅 Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
💓 Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

(For context, I'm basically referring to Python 3.12 "multiprocessing.Pool Vs. concurrent.futures.ThreadPoolExecutor"...)

Today I read that multiple cores (parallelism) help in CPU bound operations. Meanwhile, multiple threads (concurrency) is due when the tasks are I/O bound.

Is this correct? Anyone cares to elaborate for me?

At least from a theorethical standpoint. Of course, many real work has a mix of both, and I'd better start with profiling where the bottlenecks really are.

If serves of anything having a concrete "algorithm". Let's say, I have a function that applies a map-reduce strategy reading data chunks from a file on disk, and I'm computing some averages from these data, and saving to a new file.

you are viewing a single comment's thread
view the rest of the comments
[–] onlinepersona@programming.dev 17 points 1 month ago* (last edited 1 month ago) (9 children)

Python has a Global Interpreter Lock (GIL) which has been a bane and a boon. A boon because many basic types are thread-safe as actions happen in lock step. A bane because despite having multiple threads, there's still a master coordinating them all, which means there is no parallelism but concurrency. Python 3.13 allows disabling the GIL, but I cannot say much to that since I haven't tested it myself. Most likely it means nothing is really thread safe anymore and it's up to the developer to handle that.

So, in Python, using multiple threads is not a surefire way to have a performance boost. Small tasks that don't require many operations are OK for threading, but many cycles may be lost to the GIL. Using it for I/O bound stuff is good though as the main python thread won't be stuck waiting on those things to complete (reading or writing files, network access, screen access, ...) . Larger tasks with more operations that are I/O bound or require parallelism (encoding a video file, processing multiple large files at once, reading large amounts of data from the network, ...) are better as separate processes.

As an example: if you have one large file to read then split out into multiple small files, threads are a good option. Splitting happens sequentially, but writing to disk is (comparatively) slow task that one shouldn't wait on and can be dedicated to a thread. Doing these operations on multiple large files is worth doing in parallel using multiple processes. Each process will read a file, split it, and write in threads, while one master process orchestrates the slave processes.

Of course, your mileage may vary. I've run into the issue of requiring parallelism on small tasks and the only thing that worked was moving out that logic to a cython and outside the GIL (terrible experience). For small, highly parallel operations, probably Python isn't the right language and something like Rust should be explored.

Anti Commercial-AI license

[–] Zykino@programming.dev 3 points 1 month ago* (last edited 1 month ago) (4 children)

Wow coming from C++/Rust I was about to answer that both are parallelism. I did not knew about python's GIL. So I suppose this is the preferred way to do concurrency, there is no async/await, and you won't use Qt "just" for a bit of concurrency. Right ?

We learn a little bit everyday. Thanks!

[–] onlinepersona@programming.dev 3 points 1 month ago* (last edited 1 month ago) (3 children)

IINM whether it's "true" parallelism depends on the number of hardware cores (which shouldn't be a problem nowadays). A single, physical core means concurrency (even with "hyper threading") and multiple cores could mean parallelism. I can't remember if threads are core bound or not. Processes can bound to cores on linux (on other OSes too most likely).

So I suppose this is the preferred way to do concurrency, there is no async/await

Python does have async which is syntax sugar for coroutines to be run in threads or processes using an executor (doc). The standard library has asyncio which describes valuable usecases for async/await in python.

and you won’t use At “just” for a bit of concurrency. Right ?

Is "At" a typo?

We learn a little bit everyday. Thanks!

You're welcome :) I discovered the GIL the hard way unfortunately. Making another person aware of its existence to potentially save them some pain is worth it.

Anti Commercial-AI license

[–] Zykino@programming.dev 2 points 1 month ago

and you won’t use At “just” for a bit of concurrency. Right ?

Is "At" a typo?

Yes I wanted to talk about the Qt Framework. But with that much ways to do concurrency in the language's core, I suspect you would use this framework for more than just its signal/slots feature. Like if you want their data structures, their network or GUI stack, …

I'm not using Python, but I love to know the quirks of each languages.

load more comments (2 replies)
load more comments (2 replies)
load more comments (6 replies)