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.
7 Comments
gressen@lemm.ee · 36 pts · 1y
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
maikelthedev@programming.dev · 4 pts · 1y
well at least the saw works right
BB_C@programming.dev · 5 pts · 1y
Cool and all. But missing some experiments:
lto = "off"strip = false(for good measure)bodaciousFern@lemmy.dbzer0.com · 2 pts · 1y
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
BB_C@programming.dev · 7 pts · 1y
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:https://blog.rust-lang.org/2023/11/09/parallel-rustc/
sga@lemmings.world · 2 pts · 1y
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.
FizzyOrange@programming.dev · 2 pts · 1y
What's the advantage of compiling to Rust here? Maybe it would be faster if they just skipped straight to LLVM.