New week, new Rust! What are you folks up to?
Libz Blitz review for walkdir is this week. I'll be busy collecting all the feedback from the meeting and evaluation and logging issues for them against the walkdir crate.
Also refactoring elastic_responses to avoid public fields on the response types.
2 Likes
Diving through procfs on Linux, and enumerating what kind of useful information can be found there for performance monitoring purposes.
The short-term goal would be to build a library for periodically sampling this information, the medium-term goal would be to use that to build some sort of supercharged system monitor geared towards system-wide and process-specific performance analysis on Linux, and the long-term goal would be to integrate other sources of performance data such as CPU performance monitoring counters and stack samples (via perf_events), or system call tracing tools.
At this point, I'm really still in the process of exploring the viability of this idea, and not giving any guarantee that this is going anywhere. But I think Linux could really use more hardware-agnostic and user-friendly GUI performance analysis tools.
2 Likes
Diving through procfs on Linux, and enumerating what kind of useful
information can be found there for performance monitoring purposes.
You may want to have a look at the procinfo crate, and add missing details in there (if any).
I'm still translating my fac build tool into rust. I've finally gotten it almost feature-complete, and am tracking down bugs that weren't caught by the test suite. Alas, I seem to have introduced a fair number along the way. I hope by the end of the week to be using the rust implementation of fac for my everyday work.
Interestingly, in almost all my benchmarks, the rust code outpaces the old C code. This is perhaps not as impressive as it sounds, since there were a few places where I took O(N^2) shortcuts in the C code, which is part of what motivated the rust translation in the first place. Still, it's encouraging to see that performance is working out well.
It was one of the libraries which I looked at when I was exploring the search results for "proc" and "procfs" on crates.io, along with libproc, linux_stats and procps-sys.
I think I would like to experiment with more performance-oriented interfaces (keep files open instead of opening/closing them on every sample, avoid dynamically allocating memory for every sample...) and data layouts (SoA instead of AoS...) than working in any of these existing projects will easily allow. But certainly there will also be opportunities for sharing things like procfs documentation or parsing knowhow !
I'm a game developer who has worked mostly in C++ for the past 15 years, and with some upcoming vacation time I'm starting to look into what rust has to offer. As an initial experimental project I want to try to port a small utility for working with what we simply call 'symbols'. They are 64 bit hashes used in place of strings, whose fixed size makes them easy to embed in structs and fast to compare. Frequently the string is known at compile time, and with C++ constexpr it was possible to compute the hash as a compile time constant.
Because the symbols are implemented as 8x8 binary matrices, they support easy concatenation using matrix multiplication - Concat(Symbol("abc"), Symbol("def")) produces the same result as Symbol("abcdef"). They can also strip off prefixes or suffixes by concatenating with the inverse of the hash of the leading or trailing substring: Concat(Symbol("abcdef"), Inverse(Symbol("def"))) gives you back Symbol("abc").
In C++, I was able to achieve a 2x speedup for concatenation by implementing this matrix multiplication with simd intrinsics (specifically _mm_cmpeq_epi8, _mm_and_si128, _mm_xor_si128, and _mm_shuffle_epi8). I'm hoping that in rust it will be possible to achieve similar performance. From my initial research, it looks like the simd crate cannot be used with stable rust. Are there alternative options for getting access to these lower level intrinsics?