New week, new Rust! What are you folks up to?
Probably the 7th consecutive week replying to this post. I think I have almost ported C++ masstree to Rust, and this concurrent ordered map is so blazingly fast that I am still suspicious about the benchmarks I have run O.O
It diverges in several meaningful ways compared to the original to leverage Rust's strengths where possible. I am thinking about rewriting it again using the nightly toolchain because some of the unstable features would have made the code MUCH easier to implement and maintain. Anyone interested in or looking for a high perf concurrent ordered map, please check it out ![]()
EDIT:
It's published on crates.io , you can just use "cargo add masstree --features mimalloc" to add it to your project to check it out ![]()
The standard global allocator seems to be not optimal for the allocation patterns this data structure uses, but mimalloc boosts it performance significantly.
Similar to @consistent-milk12 above, posting here for the 7th consecutive week.
I'm writing a WebAssembly parser from scratch, as my second Rust project. The focus is on helpful diagnostics and good error types. This week specifically, I'm continuing implementing support for v3 of the specification (currently it's fully compliant with v2).
My little abrdump tool is now able to extract images not only from the "samp" section but from the "patt" section too and save them as PNGs. Also, it prints a nice tree of all the properties in the "desc" section. Generating fully working brushes for Krita using the information from all three sections is still a long way to go, but I feel confident I'll get there in the end (and I am working on that this week).
Right now I support only format 6.2 (the most common) and the code is a little mess but if someone needs to extract images from a Photoshop brush here it is:
README says it can be installed using cargo, but I still have to get the project on crates.io. As I said, a little mess. ![]()
Rewriting my old particle system with Newtonian mechanics, which used vello for rendering and opencl3 for GPU programming. The old sim has many problems, leading to low performance and bugs: collision resolution and displaying energy density was done on CPU, large amounts of data had to be transferred from RAM to VRAM and back, writing shaders in C was not pleasant, interfacing with OpenCL was prone to UB.
Now that I'm ready to fully immerse into the world of GPU compute, I forced myself to finally learn shaders, and use wgpu for both compute and rendering, as well as wgsl-bindgen for safe GPU data sharing. Turns out, with SDF and instancing, my RX 560 can draw millions of circles per frame at 60 FPS (previously it was tens of thousands). It still has no collision detection, but I'll be implementing that soon, starting this week with fully GPU-based BVH implementation. Additionally, instead of treating collisions as simple elastic collisions, like with billiard balls, I'll be using repulsion forces, which is much more GPU-friendly, and also how collisions work in real life.
The purpose of this experiment is to have fun learning physics and look at cool pretty stuff moving around on the screen ![]()
I have open-sourced an internal tool I wrote during a database incident we had at work. During and after the incident we needed live data that couldn't easily be exposed through metrics (I would much rather rely on things like grafana, prometheus, and logs than what the database looks like internally re: replicas and timelines), and so this tool was built. It scans our entire database fleet in pretty much constant time (since each node is scanned on its own thread).
The tool itself is still tightly coupled to our internal hostnames and naming schemes (as well as a database catalog that you ... don't have), but feel free to take a look around at least. I'm currently open-sourcing the database catalog itself, too (albeit in go).
I had to nuke the git history due to a default password used in our development environment showing up otherwise. Unfortunate, but perhaps not very interesting. It was around 25 commits.
I've been working on a code editor as a learning project. I'm in the middle of adding a side panel for a directory tree and projects.