RustTokioBenchmark
glicol-cli
RustTokioBenchmark | glicol-cli | |
---|---|---|
1 | 8 | |
0 | 126 | |
- | 2.4% | |
2.7 | 6.4 | |
about 2 months ago | 25 days ago | |
Rust | Rust | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
RustTokioBenchmark
-
3 years of fulltime Rust game development, and why we're leaving Rust behind
> If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.
So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark
On this wee laptop the numbers are 532 vs 6381 cpu cycles when sending a message (one way) from one async thread to another (tokio) or one kernel thread to another (std::mpsc), when limited to one CPU. (It's limited to one CPU as rdtscp numbers are not comparable between different CPUs; I suppose pinning both threads to their own CPUs and actually measuring end-to-end delay would solve that, but this is what I have now.)
So this was eye-opening to me, as I expected tokio to be even faster! But still, it's 10x as fast as the thread-based method.. Straight up callback would still be a lot faster, of course, but it will affect the way you structure your code.
Improvements to methodology accepted via pull requests :).
glicol-cli
-
3 years of fulltime Rust game development, and why we're leaving Rust behind
I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:
We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.
Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.
All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.
[1] https://github.com/glicol/glicol-cli
[2] https://github.com/chaosprint/glicol
-
Ratatui
great to see tui-rs can be continued in this way!
should try ratatui for glicol-cli at some point:
https://github.com/glicol/glicol-cli
- Show HN: Glicol-CLI 0.2 – Music Live Coding in Terminal with TUI Visualisation
- Glicol CLI – music live coding in terminal
- Show HN: Glicol CLI – music live coding in terminal
- glicol-cli: music live coding in terminal powered by rust
- glicol cli: music live coding in terminal
- Glicol CLI: music live coding in your terminal
What are some alternatives?
napali - Optimization as a service TUI
edma - EDMA is an interactive terminal app for managing multiple embedded databases system at once with powerful byte deserializer support. [Moved to: https://github.com/lowlevelers/edma]
Sonic Pi - Code. Music. Live.
glicol - Graph-oriented live coding language and music/audio DSP library written in Rust
textual-web - Run TUIs and terminals in your browser