Live data from Hacker News

Rust 1.24

blog.rust-lang.org

181–190 of 215 posts

Re: Rust 1.24

#181
post #80

Earlier quoted context omitted.

I don't agree. There is a default configuration, and that configuration is very good (I've been following the process of nailing it down, and IMO it's been done very tastefully), and is the formatting used by official Rust codebases, lending it the weight of authority. I have no reason to configure it to do anything differently. But I also have no reason to forbid anyone else from formatting code as they please. What…

> But I also have no reason to forbid anyone else from formatting code as they please. What's the possible harm? Obviously the proliferation of coding formatting styles. It's not we didn't have "official styles" and formatting tools before for other languages. The greatness of gofmt, and what people love it for, is how it killed all other options.

Not sure if it was actually that, many don't seem even aware of indent, whereas I used to work in places that executed it as CVS pre-commit hook.

Re: Rust 1.24

#182
post #169
post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use. I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Pytho…

My Rust dream IDE would visually display lifetimes and how they relate to each other. :)

Re: Rust 1.24

#183
post #171

Earlier quoted context omitted.

Go is good middle ground between simplicity and being fast/dynamic.

Walk middle, sooner or later get the squish just like grape.

> Avoiding both these extremes, the Tathagata (the Perfect One) has realized the Middle Path; it gives vision, gives knowledge, and leads to calm, to insight, to enlightenment and to Nibbana.

Re: Rust 1.24

#184
post #173

Earlier quoted context omitted.

Below, steveklabnik claims these things are miniscule. Are you really sure you know what is actually slow?

If you're referring to the comment starting with "It's not a big-O thing," I think that comment says the opposite. "Generics, lifetimes, and type inference" aren't "static checks and optimization passes" (within rustc)—he says the bulk of the work is LLVM dealing with the quantity of IR rustc generates, which is exactly what you'd expect from having heavy source-level abstractions like generics and type-heavy pattern…

Edit: so, in the bit below about MIR vs non-MIR borrow checking, I went and asked niko. And he told me that -Z time-passes is pretty much misleading now. Gah. I'm leaving the comment below because I put a lot of work into it, but apparently it may not be correct.

https://github.com/rust-lang-nursery/rust-forge/blob/master/... is how you're supposed to do this these days. It's a ton of work that I don't have time to do right now, but if you look at the example HTML output linked there, for a hello world, my broader point still stands, which is "translation 78.1%". That is, taking the MIR and turning it into machine code, first through LLVM IR, is the vast, vast majority of the compile time. Not the safety checks, not some un-optimized algorithm in them.

-------------------------------------

To make this concrete, here's a project I'm working on, with -Z time-passes: https://gist.github.com/steveklabnik/c2646b209debf1f66355343...

Some annotated bits of the larger passes:

  time: 0.646; rss: 91MB expansion
This is for expanding out macros, over half a second of time.

  time: 0.338; rss: 169MB coherence checking
I'm sorta surprised this takes even a third of a second; it's never come up when I've looked at these results before. Coherence is the "you can only implement a trait for a type if you've defined at least one of them in your crate".

  time: 0.596; rss: 205MB item-bodies checking
It's early so maybe I'm slightly wrong, but I believe this pass includes the type inference stuff, because that's only done inside of function bodies. 6/10ths of a second isn't nothing, but...

  time: 0.588; rss: 219MB       borrow checking
  time: 2.566; rss: 220MB MIR borrow checking
This is actually something I'm quite surprised by. Right now, we borrow-check twice, since we're still working on the MIR-based borrow checker. I'm not sure that MIR borrow checking is supposed to be this much slower; I've pinged the compiler devs about it. Regardless, before this was introduced, we'd have shaved 2.5 seconds off of the compile time, and after the old one is removed, even if the borrowcheck doesn't get faster, we'd be shaving off half a second.

Then we get into a ton of LLVM passes. As you can see, most of them take basically no time. Ones that stick out are mostly codegen passes, which is what I was referring to with my comments above. But then we have:

  time: 5.625; rss: 413MB translate to LLVM IR
Even just turning MIR into LLVM IR takes five seconds. This completely dominates the half and third second times from before. In all:

  time: 7.418; rss: 415MB LLVM passes
So, all the other passes take two seconds out of seven, combined. Ultimately, none of this is Rust's checks as a language, this is burning away all of the abstractions into lean, mean code. Finally,

  time: 9.437; rss: 414MB translation
this is the "turn LLVM IR into binary" step. This also dominates total execution time.

Note that all of this is for an initial, clean build, so a lot of that stuff is setting up incremental builds. I deleted src, git checked it out, and then built again, and got this: https://gist.github.com/steveklabnik/1ed07751c563810b515db3f... way, way, way less work, and a faster build time overall: just five seconds.

So, anyway, yeah.

Re: Rust 1.24

#185
post #169
post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use. I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Pytho…

RLS works just fine on my Linux box, error detection and completion and formatting. Debugging is so so, not very good. But on my Mac box, it's always crashing.

Re: Rust 1.24

#186
post #151

Earlier quoted context omitted.

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

Go has a lot of complexity and slowdown around FFI due to all the internal context switching, locking, and stack management. Even if there are benefits for this use case, for such a drawback is not acceptable for a systems language intended for embedding and low level libraries.

Re: Rust 1.24

#187
post #185
post #169

Earlier quoted context omitted.

Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use. I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Pytho…

RLS works just fine on my Linux box, error detection and completion and formatting. Debugging is so so, not very good. But on my Mac box, it's always crashing.

For me it's a) crashing quite often on Windows and Linux and b) doesn't really autocomplete anything beyond really simple cases where I don't need it like "Vec::::" will give me new. But on most things it's just really awful.

Error detection, at least in VSCode is only displayed after compiling, that might be the plugin though.

Re: Rust 1.24

#188
post #182
post #169

Earlier quoted context omitted.

Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use. I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Pytho…

My Rust dream IDE would visually display lifetimes and how they relate to each other. :)

That would be a really cool feature.

Re: Rust 1.24

#189
post #129

Earlier quoted context omitted.

No idea, maybe a lot from the system headers. However, it was 20,000 lines of code that survived the preprocessor, 11,000 of which were inline or template from the project itself.

- A large fraction of compiler time is spent on code generation; how many of those lines did the compiler actually generate code for? (i.e. not unused functions or uninstantiated templates) (And in the case of uninstantiated templates, a C++ compiler doesn't even need to type check them…) - Did you have optimizations enabled?

> how many of those lines did the compiler actually generate code for?

Not many. How many lines would a comparable Rust program have to instantiate? (should be the same)

All I was trying to do was make an apples to apples comparison by discrediting the implication that the clang++ and g++ compilers are only faster because people use separate compilation units.

I think it's fair to compare Rust and C++ this way, and if Rust is slower to compile, then it's fair to ask why.

> Did you have optimizations enabled?

Yes, -O3. Also -Wall -Wextra and -fwrapv if you're interested.

Re: Rust 1.24

#190

Earlier quoted context omitted.

> There were compilers in the 90s which ran a million lines per second (on much slower computers). Those compilers performed nowhere near the level of optimization that modern compilers do. > I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow. clang++ is sure slow if it has to rebuild an entire codebase from scratch. The main reason that C++ comp…

> Those compilers performed nowhere near the level of optimization that modern compilers do. I think this gets at Wirth's law a bit. Yes compilers perform lots of optimizations now, but in Rust's case it is at least partly because they need to in order to claw back the performance that the Rust gives up with its abstraction (as seen in debug builds). I do much prefer Rust's safe abstractions to writing more direct co…

> I think this gets at Wirth's law a bit.

I think Proebsting's law is also relevant. Compilers did an impressive job of optimization in the 90s, and while yes there have been advancements in the last 18 years, it's foolish to over-estimate the progress.

Also, considering how much hardware changes have improved performance (speculative execution, register renaming, etc...), it wouldn't surprise me if many compiler optimizations have become less important with time. For instance, peep-hole instruction scheduling has to matter less than it once did.

Post reply on HN