Instead of emitting one giant crate containing everything, we tweaked our SQL-to-Rust compiler to split the output into many smaller crates. Each one encapsulating just a portion of the logic, neatly depending on each other, with a single top-level main crate pulling them all in.
They changed the graphic already but holy AI on a stick! Now his arm is still behind the saw but his fingers are already gone. Lol
well at least the saw works right
Cool and all. But missing some experiments:
- cranelift
- multi-threaded rustc
- undoing type erasure after the split
lto = "off"strip = false(for good measure)- [PRIORITY] a website that works with Tridactyl✋
[PRIORITY] a website that works with Tridactyl✋
A man of culture.
multi-threaded rustc
I am still quite ignorant of the workings of rust/rustc (I’ll learn it tomorrow, I swear!) but I’m surprised that multi threaded compilation isn’t available by default. make/gcc have had it for several decades
makeuses multiple processes for parallelism, or what the blog post (below) calls “interprocess parallelism”. cargo/rustc has that and intraprocess parallelism for code generation (the backend) already. the plan is to have parallelism all the way starting from the frontend. This blog post explains it all:
What’s the advantage of compiling to Rust here? Maybe it would be faster if they just skipped straight to LLVM.
Impressive improvement! But why did they choose Rust to compile on demand in the first place, if compile time was that important?
i don’t really know how much could they optimise more, but they can predict it by fitting the number of cores with the amount of time taken, that is amdahl’s law.
