The Cranelift website does have that quote, but the linked paper says

> The resulting code performs on average 14% better than LLVM -O0, 22% slower than LLVM -O1, 25% slower than LLVM -O2, and 24% slower than LLVM -O3

So it is more like 24% slower, not 14%. Perhaps a typo (24/14), or they got the direction mixed up (it is +14 vs -24), or I'm reading that wrong?

Regardless, those numbers are on a particular set of database benchmarks (TPC-H), and I wouldn't read too much into them.

Even 14% would be unacceptably slow for a system language.

I don’t think that means it’s not doable, though.

The artifact's executions speed doesn't seem to be Cranelift's priority. They're instead focusing on compilation speed and security. Those are still useful in Rust for debug builds at least. That's when we need a quick turnaround time and as much verification as possible.

Interesting. Thanks for those numbers. I'd be interested in trying some real-world applications myself.

Besides the potential typo noted by another comment, I'd also note that the benchmarks are on a WebAssembly compiler, which has already gone through the LLVM wringer and thus undergone many high-level optimizations, including those reliant on alias analysis (which Cranelift is quite conservative on, iirc). I'd also imagine that the translation from LLVM IR to WASM discards some useful information that the LLVM backend could otherwise have used to generate better assembly.

That's not to say Cranelift isn't a fantastic piece of tech, but I wouldn't take the "14%" or "24%" number at face value.