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

Three months of Rust

scattered-thoughts.net

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Three months of Rust

#41

Post by pjmlp »

pcwalton wrote: post #17
andrewchambers wrote: post #14

Earlier quoted context omitted.

What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.

On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amo…

I think a big issue is that even if it takes a few more seconds, it is still a big win compared with C and C++ builds, usually measured in hours.

But I guess it is a block for those used to programming languages with traditional interpreter implementations.

My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are pretty acceptable for 1.0.

Re: Three months of Rust

#42

Post by jamii »

Manishearth wrote: post #39
jamii wrote: post #36

Earlier quoted context omitted.

> Those are the constraints that cannot currently be expressed in bounds, not where clauses. Yeah, I got that whole thing totally wrong. I've removed that part of the post and linked to this discussion instead. Thankyou for de-confusing me :) > The second argument can never be self. It's always the first. I think we are talking past each other on this point. I'm thinking of the design-time choice between eg: trait Ob…

Oh, I get it now. Yeah, any of these choices will work^. Well, the last choice shouldn't be a trait, really, just a standalone function. Associated types would also help simplify this (note, if you have a trait Foo , the trait can be implemented multiple times on the same type, with different A. If you have a trait Foo with associated type A, only one implementation will be allowed, the associated type is a property…

> the trait can be implemented multiple times on the same type, with different A

That was the intention - a function that dispatches on the type of both arguments (it probably shows that I secretly think of traits as typeclasses). I'm still trying to figure out what the implications of the above choices are.

> In more complicated situations coherence may disallow one or more of those choices.

I hadn't thought of that. If the trait is in another crate, does coherence require that the self type is in this crate or that all the types are in this crate? How do the coherence rules work if I don't have self type?

Re: Three months of Rust

#43

Post by plq »

glandium wrote: post #19
mbrubeck wrote: post #16

Earlier quoted context omitted.

The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.

It's also a "let's rebuild everything every time" problem. Hopefully, that will be fixed with support for building incrementally. (Also note that compiling a C++ file with 2000 lines can take a very long time too)

You must not forget that thanks to the preprocessor, what looks like 2000 lines may in fact be around 200k lines

E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l

Re: Three months of Rust

#44

Post by Manishearth »

jamii wrote: post #42
Manishearth wrote: post #39

Earlier quoted context omitted.

Oh, I get it now. Yeah, any of these choices will work^. Well, the last choice shouldn't be a trait, really, just a standalone function. Associated types would also help simplify this (note, if you have a trait Foo , the trait can be implemented multiple times on the same type, with different A. If you have a trait Foo with associated type A, only one implementation will be allowed, the associated type is a property…

> the trait can be implemented multiple times on the same type, with different A That was the intention - a function that dispatches on the type of both arguments (it probably shows that I secretly think of traits as typeclasses). I'm still trying to figure out what the implications of the above choices are. > In more complicated situations coherence may disallow one or more of those choices. I hadn't thought of that…

Traits are typeclasses :)

Uh, the coherence rules are complicated and I forgot them. It's a mixture of where the impl, type, trait, and type parameters are.

Re: Three months of Rust

#45

Post by kibwen »

prewett wrote: post #37
bsder wrote: post #30

Earlier quoted context omitted.

I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.

C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking…

Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk:

https://wiki.gnome.org/GUADEC/2015/BOFs/Rust

Some preliminary work towards this:

https://github.com/gi-rust/glib-sys

Re: Three months of Rust

#46

Post by Dewie3 »

andrewchambers wrote: post #7

"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from sour…

> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out.

Be more specific.

Re: Three months of Rust

#47

Post by stevedonovan »

andrewchambers wrote: post #7

"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from sour…

C++ isn't so bad either. 2400 loc is a really dinky program; we have a 10,000 loc C++11 program which takes 10s for a full rebuild; typical rebuild times are about a second. I don't know how rust handles incremental rebuilds, but that kind of build time feels excessive.

Re: Three months of Rust

#48

Post by tormeh »

pcwalton wrote: post #35
legutierr wrote: post #15

Earlier quoted context omitted.

If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major aspects of its design. It shouldn't be surprising that Go blows other systems out of the water in this regard. Here he is talking about it: https://www.youtube.com/watch?v=rKnDgT73v8s#t=8m53

My point is that you pay a price for this: LLVM's optimization passes are much, much more sophisticated than those of the Plan 9 toolchain. In optimized builds of Rust, the LLVM optimization and compilation time tends to dominate, so having a simpler type system wouldn't really help. You could have a more C-like language that isn't so dependent on expensive optimization passes like multi-level inlining and SROA, gran…

If optimization is the problem, then compilation at Go speed should be possible with -O0.

Re: Three months of Rust

#49

Post by tatterdemalion »

This is a super interesting read! Having come into Rust from an experience with mostly object-oriented languages (Python, Java, C++), what you seem to have taken for granted, I found surprising and new, and what you are surprised by (such as self parameters), I found quite normal. It's great to see the other side of this.

Re: Three months of Rust

#50

Post by edmccard »

andrewchambers wrote: post #7

"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from sour…

Other comments have mentioned LLVM (and its optimization passes) as a reson for slow compile times; just for comparison, using LDC (the D compiler with LLVM backend) on an older computer (1.6 Ghz Athlon 2650e, 2G ram, spinning rust), for a release build at -O2, it takes about 35 seconds for 10,000 sloc
Post reply on HN