Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust compiler performance

kobzol.github.io

Post reply on HN
Print view View original

221–230 of 264 posts

Re: Rust compiler performance

#221

Post by ninkendo »

littlestymaar wrote: post #197
ninkendo wrote: post #187

Earlier quoted context omitted.

The point of my argument is not to say I’m vetting anything, but to say that there are tons of eyeballs on crates today, because of the fact that they are distributed as source and not a binary. It’s not a silver bullet but every little bit helps, every additional eyeball makes hiding things harder. The original claim is that “pretty much no one” reads any of their dependencies, in order to support a claim that they…

> The original claim is that “pretty much no one” reads any of their dependencies, No the claim is that very few people read the dependencies[1] enough to catch a malicious piece of code . And I stand by it. “Many eyeballs” is a much weaker guarantee when people are just doing “go to definition” from their code (for instance you're never gonna land on a build.rs file this way, yet they are likely the most critical pi…

> No the claim is that very few people read the dependencies[1] enough to catch a malicious piece of code.

You’re shifting around between reading enough to catch any issue (which I could easily do if a vulnerability was right there staring at me when I follow symbol) to catching all issues (like your comment about build.rs.) Please stick with one and avoid moving goal posts around.

There exists a category of dependency issues that I could easily spot in my everyday reading of my dependencies’ source code. It’s not all of them. Your claim is that I would spot zero of them, which is overly broad.

You’re also trying to turn this into a black-or-white issue, as if to say that if it isn’t perfect (ie. I don’t regularly look at build.rs), it isn’t worth anything, which is antithetical to good security. The more eyeballs the better, and the more opportunities to spot something awry, the better.

Re: Rust compiler performance

#222

Post by maccard »

windward wrote: post #210
maccard wrote: post #106

Earlier quoted context omitted.

About 15 seconds, because we carve it up into 100 or so dlls specifically for this case

15 seconds plus the months of developer time defining dll boundaries and writing pimpls

No PIMPL's, but yes to dll boundaries. Breaking up the code into logical dependency structyures makes sense - the DLL's are no different to crates in rust really.

Re: Rust compiler performance

#223

Post by MrJohz »

kibwen wrote: post #125
MrJohz wrote: post #122

Earlier quoted context omitted.

If you look at how macros are mostly used, though, a lot of that stuff could be replaced directly with reflection. Most derive macros, for example, aren't really interested in the syntax of the type they're deriving for, they're interested in its shape, and the syntax is being used as a proxy for that. Similarly, a lot of macros get used to express relationships between types that cannot be expressed at the type syst…

I'm not intending to say that reflection is useless, but rather to say that judging macros harshly due to not being reflection would be incorrect.

But the point is that if you've got reflection (and an expressive base language, and a powerful enough type system, etc), you probably don't need macros. They're a heavy mallet when you almost always need a more precise tool. And the result of using macros is almost always worse than using that more precise tool - it will be harder to debug, it will play worse with tools like LSPs, it will be more complicated to read and write, it will be slower, etc.

I think macros are a necessarily evil in Rust, and I use them myself when writing Rust, but I think it's absolutely fair to judge macros harshly for being a worse form of many other language features.

Re: Rust compiler performance

#224

Post by muth02446 »

norir wrote: post #27

Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture. Rust can likely never be rearchitected without causing a disastrous schism in the community,…

The key to unlocking a 10x improvement to compilation speeds will like be multithreading. I vaguely remember that LLVM struggled with this and I am not sure where it stands today. On the frontend side language (not compiler) design will affect how well things can be parallelized, e.g. forward declatations probably help, mandatory interprocedural anaylyses probably hurt.

Having said that, we are in a bad shape when golang compiling 40kLOC in 2s is a celebrated achievement. Assuming this is single threaded on a 2GHz machine, we 2s * 2GHz / 40kLOC = 100k [cycles] / LOC

That seems like a lot of compute and I do not see how this cannot be improved substantially.

Shameless plug: the Cwerg language (http://cwerg.org) is very focussed on compilation speeds.

Re: Rust compiler performance

#225

Post by throwaway664786 »

jplusequalt wrote: post #17

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest.

* It's not beating interpreted languages any time soon, but that's not really a fair comparison.

Re: Rust compiler performance

#226

Post by kzrdude »

jplusequalt wrote: post #199
sagarm wrote: post #132

Earlier quoted context omitted.

Go has a lot less going on than Rust partially because compile times were a priority.

Rust has long compilation times because the borrow checker was a priority. They're very different languages.

The borrow checker is a very small factor in rust compile time

Re: Rust compiler performance

#227

Post by uecker »

imtringued wrote: post #215
saghm wrote: post #140

Earlier quoted context omitted.

The lexer hack is a C thing, and Ive rarely heard anyone complain about C compiler performance. That seems more like an argument that the grammar doesn't have that much of an impact on compiler performance as other things.

Yeah. It's exactly backwards, because good language design doesn't make anything except parsing faster. The problem is that some languages have hideously awful grammars that make things slower than they ought to be. The preprocessor approach also generates a lot of source code that then needs to be parsed over and over again. The solution to that isn't language redesign, it's to stop using preprocessors.

The preprocessor does not necessarily create a lot of source code in C. I can, if you expand arguments multiple times and there is an exponential explosion for nested macros, but this also easy to avoid.

Re: Rust compiler performance

#228

Post by uecker »

littlestymaar wrote: post #135
uecker wrote: post #88

Earlier quoted context omitted.

While LLVM is known to be slow, not all LLVM-based languages are equally slow.

This isn't an issue with LLVM being slow, but of rustc not calling LLVM efficiently, read the linked blog post!

I guess this was my point.

Re: Rust compiler performance

#229

Post by nicoburns »

littlestymaar wrote: post #141
nicoburns wrote: post #92

Earlier quoted context omitted.

> Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. Eh, it does, but it's not currently very good at this in my experience. Nothing unfixable AFAIK (and the parallel frontend can help (but is currently a significant regression on small crates)), but currently splitting things into smaller crates can often lead to much faster compiles.

Yes the actual implementation is far from what could be, but the argument was that it's not a language design issue, but an implementation one.

Agreed on that

Re: Rust compiler performance

#230

Post by nicoburns »

cesarb wrote: post #108
CrendKing wrote: post #104

Earlier quoted context omitted.

Why can't Cargo have a system like PyPI where library author uploads compiled binary (even with their specific flags) for each rust version/platform combination, and if said binary is missing for certain combination, fallback to local compile? Imagine `cargo publish` handle the compile+upload task, and crates.io be changed to also host binaries.

> Why can't Cargo have a system like PyPI where library author uploads compiled binary Unless you have perfect reproducible builds, this is a security nightmare. Source code can be reviewed (and there are even projects to share databases of already reviewed Rust crates; IIRC, both Mozilla and Google have public repositories with their lists), but it's much harder to review a binary, unless you can reproducibly recrea…

> Unless you have perfect reproducible builds

Or a trusted build server doing the builds. There is a build-bot building almost every Rust crate already for docs.rs.

Post reply on HN