Remix.run Logo
groundzeros2015 15 hours ago

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 multiple processes using various cores (databases, web servers, etc) it usually doesn’t make sense as a performance tool.

And on an embedded device you want to save power so it also rarely makes sense.

MrJohz 14 hours ago | parent | next [-]

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

fauigerzigerk 13 hours ago | parent [-]

>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 11 hours ago | parent [-]

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.

pirocks 14 hours ago | parent | prev | next [-]

> 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 13 hours ago | parent [-]

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.

NetMageSCW 15 hours ago | parent | prev [-]

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 15 hours ago | parent [-]

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?

sebtron 14 hours ago | parent | next [-]

> 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

[2]https://github.com/astral-sh/ruff

allreduce 14 hours ago | parent | prev | next [-]

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, ...).

tcfhgj 15 hours ago | parent | prev [-]

> Are people making user facing apps in rust with GUIs?

yes

groundzeros2015 15 hours ago | parent [-]

got any to share? Should I assume native gui in these these rust performance debates?

tcfhgj 14 hours ago | parent | next [-]

https://system76.com/cosmic

https://helix-editor.com/

https://zed.dev/

groundzeros2015 12 hours ago | parent [-]

What do you think are good use cases for multi threading in these editors?

steveklabnik 11 hours ago | parent | next [-]

"don't block the ui thread" is a pretty classic aphorism in any language.

tcfhgj 12 hours ago | parent | prev [-]

search, linting

gf000 14 hours ago | parent | prev | next [-]

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 12 hours ago | parent [-]

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 12 hours ago | parent [-]

> 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 12 hours ago | parent [-]

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.

xpe 14 hours ago | parent | prev [-]

You might start with https://github.com/zed-industries/awesome-gpui and https://blog.logrocket.com/state-rust-gui-libraries/