I’ve written a work-stealing task queue system for high-performance, CPU-bound applications, called takeaway. It provides an intuitive high-level API and its internal architecture allows it to provide some unique features. I wrote it because the only popular work-stealing library for Rust, crossbeam-deque, does not support task prioritization, a feature I need for my very-very-WIP Rust compiler (krabby).
It’s taken 2 months of work, but I’m really happy with the current state of takeaway. I’ve released v0.1.0 as the first “stable” release; I expect to make some (minor) breaking changes in the future, but I think it’s ready for public use. If you’re writing a high-performance, task-based application like me, please check it out! It offers competitive (and often better) performance than crossbeam-deque, with a nicer API and more features. Over here, I’m going to expand on takeaway’s design and the process of implementing it.
read more…
Continuing on from the proof of concept, I’m making good progress on Krabby! There are three major steps I’ve accomplished in the last two weeks: a faster TOML parser, a custom lexer, and most importantly, the completion of the task architecture. I will need all of this infrastructure before I can tackle name resolution, and it’s coming together very well.
read more…
This week has been incredibly productive. I was one of the volunteers for RustWeek, which was a massive event with ~800 attendants and the first All-Hands (gathering of all Rust contributors) in over 6 years. I met so many amazing figures in the Rust community, and I had really interesting conversations with them about compiler performance and Krabby. I’m incredibly gratified to have received confirmation that I’m on the right track with this work, and I’m incredibly excited to see where I can take Krabby in the future.
read more…
I felt a bit stuck this week. While I have developed an interesting AST to experiment on, going any further with it is difficult. The next major step is name resolution, and that will require the ASTs of different files to interact with each other. My current testing / benchmarking setup, while good for executing things per file, can’t deal with that. Now that I know these memory layout techniques will be effective, I decided to start over with a focus on krabby’s high-level architecture.
read more…
In my previous post about krabby, I made a “scope tree” data structure with which I performed local name resolution. It was incredibly efficient compared to syn’s AST, but I wanted a more realistic comparison of this memory layout style to syn. So I spent most of this week building a whole AST from scratch.
read more…
I was planning to write a post about the overall architecture I envision for krabby, but there are some complicated bits (regarding macro expansion) that don’t feel resolved yet. Maybe that’ll come next week.
In the meantime, I decided to tackle the first non-trivial (but relatively simple) compilation stage I could think of: local name resolution. This doesn’t try to resolve imports or references to items (e.g. functions), but rather only the variables defined within a function body. While my code certainly isn’t perfect, it was a great experiment, and it’s helped me figure out parts of the compiler infrastructure that will be crucial as we go on.
read more…
A couple of friends got together and, waddaya know, a new programming language project was born. We have no idea where it’s going, or how feasible it is, but we’re all pretty excited. We wanted to see where we could go from Rust, and there’s some pretty wild ideas being thrown about. It’s really fun!
read more…