Live data from Hacker News

Rust: Zero-Cost Abstraction in Action

idursun.com

41–46 of 46 posts

Re: Rust: Zero-Cost Abstraction in Action

#41
post #15

These are not about abstractions but compile time optimizations. These are also not implemented in the Rust compiler but LLVM. So any any language frontend in front of LLVM would yield the same optimizations. According to Wikipedia the list is: > [...] variety of front ends: languages with compilers that use LLVM include ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Dylan, Fortran, Graphical G Program…

Even worse, the lack of proper compiler design courses in many universities or "engineer" bootcamps, means that many attribute to language X, what is actually a compiler backend capability, like you quite well explain.

Re: Rust: Zero-Cost Abstraction in Action

#42
post #16
post #15

These are not about abstractions but compile time optimizations. These are also not implemented in the Rust compiler but LLVM. So any any language frontend in front of LLVM would yield the same optimizations. According to Wikipedia the list is: > [...] variety of front ends: languages with compilers that use LLVM include ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Dylan, Fortran, Graphical G Program…

The C# compiler uses LLVM? Is that for something like Xamarin or something? I was under the impression that it was self-contained. Anyone knows the details of this?

There are many implementations of C#, a few of them use LLVM, like Xamarin AOT, IL2CPP, Burst.

.NET Core and .NET Framework, do not.

Re: Rust: Zero-Cost Abstraction in Action

#43
post #35
post #27

> he was very disappointed because Rust version was twice as fast than the C version which was hand-optimised by pulling off all the tricks he knew to make it perform well. Why disappointed? It just highlights the quality of Rust's approach.

Evidently the tricks were what made it slow. This happens all too often: once the code changes enough that the optimizer doesn't recognize the pattern anymore, it throws up its hands, and you're on your own. Some people call this optimizer roulette. It's not just compilers, either. CPUs have their own peephole optimizers, and patterns they recognize, or don't, and it can easily make a 2x difference in your run time d…

With CPUs it gets even worse, because that clever optimized Assembly code can stop being so in another CPU or after a firmware update.

The days of Z80, 6502 and similar are long gone.

Re: Rust: Zero-Cost Abstraction in Action

#44
post #19
post #17

Earlier quoted context omitted.

Anyone can build a frontend. "Java bytecode" is in that list too. It doesn't mean defacto compilers of these languages rely on LLVM.

In this case it is Azul Zing, a very serious product. It's one of the four major VM Jit compilers (OpenJ9, C2, Graal are the others in my opinion) [1] https://www.azul.com/products/zing/

There are also PTC, Aicas, Virtenio, Ricoh and Gemalto all targeted to embededded deployments, of which, PTC and Aicas are the most well known ones.

Sadly Excelsior is no more. I imagine that regular JIT compilers making AOT/JIT caches available, is what killed them.

Re: Rust: Zero-Cost Abstraction in Action

#45

The ocaml compiler does constant folding too, and I consistently look at the (usually javascript because of Bucklescript) output in amazement when it finds shit like that. Unrolling all my tail recursion is great too.

For anyone that wants to learn about optimizations in AOT compiled ML languages, have a look at:

"The Implementation of Functional Programming Languages"

"Compiling with Continuations"

"Modern Compiler Implementation in ..." (C, Java and ML variants)

Although oriented towards Lisp, "Lisp in small pieces" is a classical book as well, with many optimizations like inlining of lambda calls across multiple call levels.

Re: Rust: Zero-Cost Abstraction in Action

#46

The earlier transformations are actually more impressive. Constant folding is almost always has a good RoI, so lots of compilers do it, and it's simple because, well, it's a constant there is no variables or partial eval needed. The others require lots of inlining before the final rule fires, and so are more ambitious. Seeing what pub fn sum3(n: i32) -> i32 { (1..n).sum() + (1..2*n).sum() + (1..(n + 2)).sum() } does…

Godbolt supports Rust, and can show the LLVM IR: https://godbolt.org/z/GsccW3

A bit offtopic, I love how Godbolt grew out of C++ community to embrace as much AOT toolchains as possible, kudos to Matt and everyone involved into making it happen.
Post reply on HN