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

231–240 of 264 posts

Re: Rust compiler performance

#231

Post by littlestymaar »

ninkendo wrote: post #221
littlestymaar wrote: post #197

Earlier quoted context omitted.

> 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 dependen…

I'm not moving the goal post, a supply chain attack is an adversarial situation it is not about spotting an issue occurring at random, it is about spotting an issue specially crafted to avoid detection. So in practice you are either able to spot every kind of issues, or none of the relevant ones because if there's one kind that reliably slips through, then you can be certain that the attacker will focus on this kind and ignore the trivial to spot ones.

If anything, having access to the source code gives you an illusion of security, which is probably the worse place to be in.

The worse ecosystem when it comes to supply chain attacks is arguably the npm one, yet there anyone can see the source and there are almost two orders of magnitude more eyeballs.

Re: Rust compiler performance

#232

Post by Kranar »

MrJohz wrote: post #223
kibwen wrote: post #125

Earlier quoted context omitted.

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…

No disagreement on your point, but this is a different argument than claiming that macros are an ugly hack to workaround lack of reflection.

Because Rust lacks reflection macros are used to provide some kind of ad-hoc reflection support, that much we agree... but macros are also used to provide a lot of language extensions other than reflection support. Macros in general exist to give users some ability to introduce new language features and fill in missing gaps, and yes reflection is one of those gaps. Variadics are another gap, some error handling techniques is yet another, as are domain specific languages like compile time regex! and SQL query macros.

Re: Rust compiler performance

#233

Post by hinkley »

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,…

If the application works poorly for the developers it will eventually work poorly for everyone.

Being surrounded by suck slowly creeps into the quality of your work.

Computer programming is the only skilled labor I know of where people eschew quality tools and think they won’t output slop by doing so.

Re: Rust compiler performance

#234

Post by hinkley »

pjmlp wrote: post #161
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,…

Not only language. Many of complaints towards Rust, or C++, are in reality tooling complaints. As shown on other ecosystems, the availability of interpreters or image based tooling are great ways to overcome slow optimizating compilers. C++ already had a go at this back in the early 90's with Energize C++ and Visual Age for C++ v4, both based on Common Lisp and Smalltalk from their respective owners. They failed on t…

I had a coworker who was using Rational back then, and found out one of its killer features was caching of pre compiled headers. Whoever changed them had to pay the piper of compilation, but everyone else got a copy shipped to them over the local network.

Re: Rust compiler performance

#235

Post by hinkley »

maccard wrote: post #60
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.

I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand li…

30 minutes versus 60 is really an hour versus two.

Some coworkers and I noticed a long time ago that once you try to task switch while doing build/test automation steps, it always seems like you remember to come back and check about twice as long as the compile was supposed to take. 7+ turned into 15, 15 into a half hour.

And then one day it hit me that this is just Hofstadter’s Law. You think you have ten minutes so you start a ten minute task and it takes you twenty, or you get in a flow and forget to look until your senses tell you you’re forgetting something.

Cutting 10 minutes off a build really averages 20 minutes in saved time per cycle. Which matters a hell of a lot when you go from 4 to 5 cycles per 8 hour day.

Re: Rust compiler performance

#236

Post by [deleted] »

jtrueb wrote: post #38

A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, wh…

[deleted]

Re: Rust compiler performance

#237

Post by MrJohz »

Kranar wrote: post #232
MrJohz wrote: post #223

Earlier quoted context omitted.

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…

No disagreement on your point, but this is a different argument than claiming that macros are an ugly hack to workaround lack of reflection. Because Rust lacks reflection macros are used to provide some kind of ad-hoc reflection support, that much we agree... but macros are also used to provide a lot of language extensions other than reflection support. Macros in general exist to give users some ability to introduce…

But the point is that almost all of the common places where macros are used in everyday Rust could be replaced by reflection. There are exceptions like some of the ones you mention, but these are clever hacks rather than materially useful. Yes, you can write inline SQL and get it type checked, but you can also use a query builder or included strings and get the same effects but in a much less magical and brittle package.

Macros in Rust are primarily a tool to handle missing reflection capabilities, and them enabling other code as well is basically just a side effect of that.

Re: Rust compiler performance

#238

Post by bmitc »

Ar-Curunir wrote: post #116
dvt wrote: post #109

Earlier quoted context omitted.

I like Rust, but I think this post is unfairly downvoted. Rustaceans often annoyingly point out that "you can't use super-common-footgun X with Rust!" which, while true, they also omit the compromises made are immense (frankly, compiler performance is one of them).

The parent did not mention any of these compromises, beyond claiming that they are uncommon (which is untrue for many domains)

They are uncommon in many languages though that don't require Rust's type system, such as functional languages that simply pass values around and nothing else.

Re: Rust compiler performance

#239

Post by felipeccastro »

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,…

It is ironic how “rewrite it in Rust” is the solution to make any program fast, except the Rust compiler.

Re: Rust compiler performance

#240

Post by ninkendo »

littlestymaar wrote: post #231
ninkendo wrote: post #221

Earlier quoted context omitted.

> 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 dependen…

I'm not moving the goal post, a supply chain attack is an adversarial situation it is not about spotting an issue occurring at random, it is about spotting an issue specially crafted to avoid detection. So in practice you are either able to spot every kind of issues , or none of the relevant ones because if there's one kind that reliably slips through, then you can be certain that the attacker will focus on this kind…

In such an environment I’m doomed anyway, even if I’m vetting code. I don’t understand why the goal has to be “the ability to spot attacks specifically designed to prevent you from detecting.” For what you’re describing, there seems to be no hope at all.

It’s like if someone says “don’t pipe curl into bash to install software”, ok that may or may not be good advice. But then someone else says “yeah, I download the script first and give it a cursory glance to see what it’s doing”, wouldn’t you agree they’re marginally better off than the people who just do it blindly?

If not, maybe we just aren’t coming from any mutual shared experience. It seems flatly obvious to me that being able to read the code I’m running puts me in a better spot. Maybe we just fundamentally disagree.

Post reply on HN