btop
btop copied to clipboard
aristocratos
Rewrite in Rust
Hi, I think that the program needs just one more FINAL rewrite but this time in the powerful ~~HolyC~~ Rust. It would be the final solution to all of our problems. Could you explain why did you rewrote the entire thing for the 2nd time? PS. Don't take it too seriously. I just couldn't stop laughing on that announcement and couldn't stop myself from writing it. I really appreciate your hard work. Just the situation is a great meme. :D
As I've said before, the final form will be when re-written in assembly as asstop.
The reason for rewriting again was because speed! And I really wanted to learn C++. And having learnt a fair amount of it I'm probably gonna stick with it. You can get surprisingly much done with not that much code using C++20, while also having the ability to mess up your own code (or system) on a very low level :)
So does that mean it's R.I.P (rust in peace) for the Rust rewrite? :upside_down_face:
@pm4rcin tried this. Did not go well. Complete overhaul of multithreading would need to be done... https://github.com/StappsWorld/brshtop
@StappsWorld Wow, hadn't seen that before :)
Honestly, I think you could get away with running single threaded, if you get the same speed as btop for the collection functions, all collection should be done in under 30ms (in 99% of cases) even on slow systems (under 10ms on modern cpus). So shouldn't give any perceivable lag. Might need some changes to input handling though, to sort out multiple input events buffered during collect.
No joke. I'm really interested how this project would turn out in Rust. And medium.com article about your feedback and experience with deep comparasing would be superb! Same project written in Python, Go, Rust and C++! It'll be all over internet and ThisWeekInRust too.
@aristocratos I wrote this while in the process of learning Rust. Honestly, a lot of my codebase is pretty bad. If you pull brshtop and run the code, it locks right as you start the main loop as of right now. I can't remember exactly what causes the issue, but if I remember correctly it's because of the borrow checker not allowing interior mutability on events (so you can have an event attempt to lock the main loop for a collector, but it never unlocks since you can't mutate it's flag). I may be wrong as it's been over half a year, but I'm thinking about rewriting brshtop as a whole if you're interested!
@StappsWorld
but I'm thinking about rewriting brshtop as a whole if you're interested!
You should go for it :) I reckon the C++ sources are better suited for porting considering I'm not using any libraries except the standard library and a custom hash map library.
I'm gonna be pretty busy still writing OsX, FreeBSD and GPU support though, so I don't think I will delve in to Rust myself right now. But if you got any questions about the sources and/or functionality I'll give any help I can.
I'm am pretty curious about the performance of C++ vs Rust in a program like this. All general benchmarks between the languages I've seen so far have been all over the place. Though it could be that there's no difference at all, since right now about 90-95% of the time it takes for a collection cycle, is spent waiting for the kernel when polling all processes from /proc and other system calls (which should be the same regardless of language).
gigabyte sized binaries dedicated just to useless debug information
Release builds are a thing, just don't compile a debug build...
Language is somehow more confusing than Haskell
It's a low level system programing language, it's barely more difficult than C or C++
Slow compiling times
Ofc, it does a lot at compile time.
Mozilla
Mozilla doesn't own Rust. The Rust Foundation is a thing.
gigabyte sized binaries dedicated just to useless debug information
Release builds are a thing, just don't compile a debug build...
Language is somehow more confusing than Haskell
It's a low level system programing language, it's barely more difficult than C or C++
Slow compiling times
Ofc, it does a lot at compile time.
Mozilla
Mozilla doesn't own Rust. The Rust Foundation is a thing.
I don't know what was into me that day sorry
Release builds are a thing, just don't compile a debug build...
Rust still has the problem of large binaries however even with release mode compared to C or C++ which makes it perhaps unpractical for very embedded devices but I guess this isn't too big of a deal
Language is somehow more confusing than Haskell
I should rephrase that, Rust is hard to understand since it has new concepts compared to C
I'm am pretty curious about the performance of C++ vs Rust in a program like this. All general benchmarks between the languages I've seen so far have been all over the place. Though it could be that there's no difference at all, since right now about 90-95% of the time it takes for a collection cycle, is spent waiting for the kernel when polling all processes from
/procand other system calls (which should be the same regardless of language).
It's all over the place since Rust uses LLVM it's a lot like assembly but more high level and gets optimized unlike assembly where what you do is what you get in the binary
LLVM is about the same as GCC these days in terms of speed
The only way this would change is if Rust made their own compiler 100% from scratch instead of piggybacking off LLVM, but it would likely be too much effort however Zig and Go do this
https://kristoff.it/blog/zig-new-relationship-llvm/
@nonetrix
Rust still has the problem of large binaries however even with release mode compared to C or C++ which makes it perhaps unpractical for very embedded devices but I guess this isn't too big of a deal.
C is basically cheating here though because the C standard library is included in every major operating system and programs link to it. Rust doesn’t have the luxury of convincing operating systems to include its runtime as a core OS component. Binary sizes should be a lot more comparable when you aren’t linking that standard library in. I have written Rust for the Commodore 64 before and the code is actually really small. You can also get it to throw out most of the standard library by using LTO, which will make your compile times even longer, but I think it’s worth it.
Nah, I’m not in the mood to get super passionate about it or anything. I know this is a joke issue. I just wanted to respond to some serious comments with some serious comments. I don’t care what language my system monitor program is written in as long as it isn’t Bash or Python. :D
What's wrong with htop? I like other monitors but when I want to kill a process or have good process overview it's probably unbeatable.
I use it as well. It is fine. I honestly like some variety. Peering into what the system is up to is fun in general.
Rust still has the problem of large binaries however even with release mode compared to C or C++ which makes it perhaps unpractical for very embedded devices but I guess this isn't too big of a deal
This repository might give some additional help in that regard: https://github.com/johnthagen/min-sized-rust This repository demonstrates how to minimize the size of a Rust binary.
