New week, new Rust! What are you folks up to?
2 Likes
9th consecutive week replying to this post :'D
I am mostly done working on the core API of the masstree port. I am starting to think that it could actually be the fastest concurrent ordered map available in Rust O.O Feel free to add more stress tests and benchmarks to break it or slow it down, I tried my best 
I am thinking about expanding my pstd crate.
Crate with parts of Rust std library ( different implementations, features not yet stabilised etc ).
2 Likes
I always wanted to do this after I read the comments in btreemap module explaining how it wasn't fully optimized :'D
I'll be continuing work on my chess engine. I'm hoping to release a new version in the next couple weeks! Playing strength is around 2300-2500 elo right now and you can play against it online if you'd like (link is in README).
3 Likes
I've been practising Rust and teaching myself concurrency by making a website link checker (sort of like the W3C Link Checker but running from the terminal) and experimenting with ways to make it fetch multiple URLs concurrently.
I started using Rust's mpsc channels, and found them to be charming but (I thought) limited for my purposes. My first approach was creating tx transmitter objects in waves of four threads at a time. Which gives nice, simple, elegant code, but also means that every URL fetch timeout would cause the entire wave to sit waiting for up to ten seconds (the timeout limit), holding up the next wave and reducing throughput.
I couldn't see a way to get around that using mpsc, so I rewrote the concurrency using an Arc<Mutex<T>> shared state approach, which was tricky, and fairly ugly, and rife with bugs at first, but it did greatly speed up the throughput because it no longer needed to wait for a wave to finish before spawning the next thread.
Unhappy with the inelegant and unsafe (but not unsafe) feeling the shared state approach gave, this week I tried again with the mpsc approach and realised you can have the rx receiver loop spawn new threads with new (cloned) tx objects, so there's no need for Arc<Mutex<T>> shared state at all for my needs. And the self-feeding mpsc approach is even faster than the shared state approach.
The wave-based mpsc approach managed 390 URL fetches per minute with four concurrent threads available. The shared state approach managed 822 per minute. The self-feeding mpsc approach managed 1,188 per minute. And throwing 256 threads at the self-feeding mpsc approach gave 10,823 URL fetches per minute, which somehow feels obscene. (Though these numbers come from checking a localhost copy of my website, so only third-party URLs need to actually be fetched over the internet. Using more than four concurrent threads against my live web server causes my web host to reject most of the HTTP requests.)
The shared state approach leaves lots more room for logic errors (forgetting to increment counters, not making state changes atomic, etc) but at least Rust's borrow checker and expressive type system spare you numerous horrors that haunt other languages. I'd still recommend going with the mpsc channels approach if you can make it work for your needs, though.
1 Like
I have been working on my cachekit crate, but wanted to do some proper benchmarking against real world workloads, but haven't found any native Rust based solutions, so have started to put together tracekit, with the idea of having a library of pimitives to generate synthetic tracing data and/or download and use real traces. Thoughts? feelings?
1 Like
Writing a new UI (actually, a web server) to browse Metamath proof database.
The palette in second column shows which of the 60 non-eliminable axioms are used to prove each theorem; the third column shows the theorem statement itself, and the fourth its description.
It's based on metamath_rs - Rust which is somewhat sparsely documented, so I have yet to parse some details like what hypotheses each theorem has. And also apparently I need to HTML-escape the output otherwise the first less-than sign "<" breaks everything.
1 Like