• 9 Posts
  • 304 Comments
Joined 1 year ago
cake
Cake day: September 1st, 2023

help-circle



  • 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



  • 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



  • Your post is nearly the epitome of Chesterton’s Fence. You don’t seem to understand why Rust looks the way it does, works the way it does, why it exists, what it’s used for, and what problems it solves, but you’re very happy (or not, which is probably why you wrote this post) to trash it.

    There are many responses to your comments that explain things quite well, yet, from what I see, you do not seem to concentrate on those.

    And what I quoted is just the icing on top. It looks very much like you have one style of programming and approaching problems (the PHP style of “if it runs, it’s good”) and apply it to every problem. You have used a hammer your whole life and every problem looks like a nail. You can build a good many things with duct tape, nails, and a hammer. It might all do the job well enough for your standards or purposes and at times it might even be the perfect tool for a task.
    But now you’ve discovered a screw driver, tried to hammer in a nail, and gotten quite frustrated that it didn’t work well. Instead of considering using a screw, you have tossed aside the screwdriver and decided to yell expletives into the ether.

    The ether has responded with explanations, but you have chosen to ignore them all and staunchly hold on to your “screwdrivers are shit” conclusion. Had you said “I’m just blowing off steam, don’t take this seriously”, that’s what it would’ve been. However, you seem quite serious. Or, as I said before, you’re just trolling.

    Anti Commercial-AI license













  • Again, the Linux kernel needs more funding. For crying out loud, these kinds of people holding back progress should be made obsolete (by bringing in and paying talent that is willing to work towards a brighter future with less memory errors, a sane tech stack with better tooling, and better processes). Holding back progress because of their incessant pearl clutching “but my dearest C!!!” Just hurts everybody and impedes progress.

    Of course blindly adding the latest and greatest is asking for trouble. Assessing risk, weighing options, making a plan and continuously assessing impact is definitely important, but straight up blocking the road on principle is extremely unproductive.

    Anti Commercial-AI license