5 ms·

Multithreading does not make code more efficient. It still takes the same amount of work and power (slightly more). On a backend system where you already have

• NetMageSCW 10mo ago
  Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.
  • groundzeros2015 10mo ago
    Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful? Are people making user facing apps in rust with GUIs?
    • tcfhgj 10mo ago
      > Are people making user facing apps in rust with GUIs? yes
      • groundzeros2015 10mo ago
        got any to share? Should I assume native gui in these these rust performance debates?
        • tcfhgj 10mo ago
          https://system76.com/cosmic https://system76.com/cosmic https://helix-editor.com/ https://helix-editor.com/ https://zed.dev/ https://zed.dev/
          • groundzeros2015 10mo ago
            What do you think are good use cases for multi threading in these editors?
            • tcfhgj 10mo ago
              search, linting
            • steveklabnik 10mo ago
              "don't block the ui thread" is a pretty classic aphorism in any language.
              • johnisgood 10mo ago
                Hmm. "Fearless concurrency" and the flagship examples are... background threads for search and not freezing the UI? That is GUI programming 101 from the Win32 era. Every Tcl/Tk app, every GTK app, every Qt app has been doing this for 25+ years. If Rust's concurrency story were genuinely revolutionary, you would expect examples like: - Lock-free data structures that are actually hard to get right - Complex parallel algorithms with non-trivial synchronization - Work-stealing schedulers with provable correctness Instead we have "we run grep in a background thread"?
                • steveklabnik 10mo ago
                  When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust! (And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)
                  • johnisgood 10mo ago
                    You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning. In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been brought up as evidence in the first place. Plus if things like work-stealing queues and complex synchronization are not relevant to editors, then editors are a poor example for demonstrating Rust's concurrency story in the first place anyway.
        • xpe 10mo ago
          You might start with https://github.com/zed-industries/awesome-gpui https://github.com/zed-industries/awesome-gpui and https://blog.logrocket.com/state-rust-gui-libraries/ https://blog.logrocket.com/state-rust-gui-libraries/
        • gf000 10mo ago
          Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?
          • groundzeros2015 10mo ago
            Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful. The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
            • gf000 10mo ago
              > The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
              • groundzeros2015 10mo ago
                And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.
                • pjmlp 10mo ago
                  No it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
      • PPanther 10mo ago
        I made this with egui and typo: https://github.com/PJaros/menu_pdf https://github.com/PJaros/menu_pdf Works under Linux and Windows.
    • sebtron 10mo ago
      > Are people making user facing apps in rust with uis? We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser! At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely appreciate a 16x speedup if possible. [1] https://github.com/astral-sh/uv https://github.com/astral-sh/uv [2]https://github.com/astral-sh/ruff https://github.com/astral-sh/ruff
      • jenadine 10mo ago
        > There are lots of C++ UI applications. Is there? UI applications historically used to be written in C++. But in this decade, I don't think many new GUI are being written in C++
        • pjmlp 10mo ago
          Games are, anything based on Qt/KDE, UWP/WinUI (even if it is mostly Microsoft employees). Now even if it is Flutter, React Native, or Chrome/Electron, they are powered by C++ graphics engine, and language runtimes.
          • estebank 10mo ago
            The engine being written in C++ does not mean the application is. You're conflating the platform with what is being built on top of it. Your logic would mean that all Python applications should be counted as C applications.
            • pjmlp 10mo ago
              Indeed too many fake Python libraries.
    • allreduce 10mo ago
      Usually it does not reduce latency but increases throughput. Multithreading is an invaluable tool when actually using your computer to crunch numbers (scientific computing, rendering, ...).
• pirocks 10mo ago
  > Multithreading does not make code more efficient. It still takes the same amount of work and power (slightly more). In addition to my sibling comments I would like to point out that multithreading quite often can save power. Typically the power consumption of an all core load is within 2x the power consumption of a single core load, while being many times faster assuming your task parallelizes well. This makes sense b/c a fully loaded cpu core still needs all the L3 cache mechanisms, all the DRAM controller mechanisms, etc to run at full speed. A fully idle system on the other hand can consume very little power if it idles well(which admittedly many cpus do not idle on low power). Edit: I would also add that if your system is running a single threaded database, and a single threaded web server, that still leaves over a hundred of underutilized cores on many modern server class cpus.
  • groundzeros2015 10mo ago
    Responding to your last point. If you use a LAMP style architecture with a scripting language handling requests and querying a database, you can never write a single line of multithreaded code and already are setup to utilize N cores. Each web request can happen in a thread/process and their queries and spawns happen independently as well.
• MrJohz 10mo ago
  According to [1], the most important factor for the power consumption of code is how long the code takes to run. Code that spreads over multiple cores is generally more power efficient than code that runs sequentially, because the power consumption of multiple cores grows less than linearly (that is, it requires less than twice as much power to run two cores as it does one core). Therefore if parallelising code reduces the runtime of that code, it is almost always more energy efficient to do so. Obviously if this is important in a particular context, it's probably worth measuring it in that context (e.g. embedded devices), but I suspect this is true more often than it isn't true. [1]: https://arxiv.org/abs/2410.05460 https://arxiv.org/abs/2410.05460
  • fauigerzigerk 10mo ago
    >Therefore if parallelising code reduces the runtime of that code, it is almost always more energy efficient to do so Only if it leads to better utilisation. But in the scenario that the parent comment suggests, it does not lead to better utilisation as all cores are constantly busy processing requests. Throughput as well as CPU time across cores remains largely the same regardless of whether or not you paralellise individual programs/requests.
    • MrJohz 10mo ago
      That's true, which is why I added the caveat that this is only true if parallelising reduces the overall runtime - if you can get in more requests per second through parallelisation. And the flip side of that is that if you're able to perfectly utilise all cores then you're already running everything in parallel. That said, I suspect it's a rare case where you really do have perfect core utilisation.