4 ms·
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
by 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 agoYes 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 agogot any to share? Should I assume native gui in these these rust performance debates?
- tcfhgj 10mo agohttps://system76.com/cosmic https://system76.com/cosmic https://helix-editor.com/ https://helix-editor.com/ https://zed.dev/ https://zed.dev/
- groundzeros2015 10mo agoWhat do you think are good use cases for multi threading in these editors?
- tcfhgj 10mo agosearch, linting
- steveklabnik 10mo ago"don't block the ui thread" is a pretty classic aphorism in any language.
- johnisgood 10mo agoHmm. "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 agoWhen 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 agoYou 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.
- steveklabnik 10mo ago
- xpe 10mo agoYou 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 agoWell, 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 agoSure. 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 agoAnd 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 agoNo it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
- PPanther 10mo agoI 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 agoGames 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.
- allreduce 10mo agoUsually it does not reduce latency but increases throughput. Multithreading is an invaluable tool when actually using your computer to crunch numbers (scientific computing, rendering, ...).