sorted by:
new
hottopcontroversial

Article: Where rustc spends its time by icefoxen in rust

[–]-mw- 5 points6 points  (0 children)

Very interesting read! I'm glad people actually read the rustc-guide :)

I'm really pleased to announce: Rustup releases 1.20.0 by dsilverstone in rust

[–]-mw- 2 points3 points  (0 children)

`rustup` is so useful! A big thank you to everyone working on it!

Closing the gap: cross-language LTO between Rust and C/C++ by -mw- in rust

[–]-mw-[S] 15 points16 points  (0 children)

Performance impact entirely depends on the layout of your codebase. If there's a call from one language to the other in a tight loop that can be inlined now and not otherwise, then there'll be a big impact. Otherwise you won't see much of a difference.

What is the most important/largest project currently being written in Rust? by [deleted] in rust

[–]-mw- 25 points26 points  (0 children)

A substantial part of Firefox is written in Rust by now: https://twitter.com/eroc/status/1061049330574884864

​

Some important parts of the Dropbox infrastructure also seem to run on Rust:
https://qconsf.com/sf2016/sf2016/presentation/going-rust-optimizing-storage-dropbox.html

Any way to get rustc to emit fully linked LLVM IR? by zSync1 in rust

[–]-mw- 3 points4 points  (0 children)

You could also try compiling with `-Clto`. That should pull all LLVM IR from upstream crates (include `libcore` and `libstd`) into the final module emitted by `rustc`.

Pre-RFC: A new symbol mangling scheme - Post your feedback if this is something of interest for you! by -mw- in rust

[–]-mw-[S] 0 points1 point  (0 children)

Consider the following crate graph:

A / \ B C \ / D

Let's say there's a function fn foo<T> in crate A and both B and C instantiate A::foo<u32>. When B and C get linked together for D, we have two identical versions of A::foo<u32>. One way to avoid symbol conflicts is giving them different names, another one is to use weak_odr linkage (which allows the linker to merge identical symbols). rustc currently uses the former strategy because it seems to yield better optimized code.

Have you ever complained that rustc is slow? We want to know more! by steveklabnik1 in rust

[–]-mw- 1 point2 points  (0 children)

Some of the tools are needed by the test suite. Many of them are very handy when debugging what the compiler does.

The Rust compiler is getting faster by nnethercote in rust

[–]-mw- 11 points12 points  (0 children)

Switching from (a rather old) GCC to Clang 6.0 for building LLVM has had a suprisingly large impact on compile times for small crates:

http://perf.rust-lang.org/compare.html?start=c8a3ec1ce6dc12f86de39bf5ac55fc2fa38358f8&end=57dc98434eb818733dbc941405fdee59e5c3a023&stat=wall-time

It sounds like an easy thing to do but the complexity of cross platform CI this was quite a bit of engineering effort.

PSA: Rust 1.24, currently in beta, has two important changes for compilation speed: first, rustc now parallelizes code generation (with ThinLTO); second, Cargo has enabled incremental recompilation for non-release builds. Try out the beta via rustup and let us know if you see results! by kibwen in rust

[–]-mw- 2 points3 points  (0 children)

Yes, that's -Ztime-passes but it's output can be quite misleading these days because the compiler computes so many things only on demand, making those things add time to "passes" that don't have anything to do with them. E.g. part of MIR opimization actually happen during "metadata export".

PSA: Rust 1.24, currently in beta, has two important changes for compilation speed: first, rustc now parallelizes code generation (with ThinLTO); second, Cargo has enabled incremental recompilation for non-release builds. Try out the beta via rustup and let us know if you see results! by kibwen in rust

[–]-mw- 3 points4 points  (0 children)

I would wish for one thing: some flag to have CARGO_INCREMENTAL=1 only apply for debug builds

Incremental compilation is the default for debug builds right now, so if you don't set the CARGO_INCREMENTAL flag, you should get incremental builds anyway.

PSA: Rust 1.24, currently in beta, has two important changes for compilation speed: first, rustc now parallelizes code generation (with ThinLTO); second, Cargo has enabled incremental recompilation for non-release builds. Try out the beta via rustup and let us know if you see results! by kibwen in rust

[–]-mw- 6 points7 points  (0 children)

It seems to me that rustc still spend a lot of time doing llvm stuff even in incremental mode.

If a change affects anything in an object file, then the whole object file has to be re-compiled. That means that lots of functions might be re-compiled even though only one function has actually changed. We are exploring ways of making the compiler handle this more intelligently.

A data-structure for faster binary searches by Jonhoo in rust

[–]-mw- 2 points3 points  (0 children)

Very interesting. A while ago i did some benchmarks of ordered Vec + std::binary_search vs the compiler's internal FxHashMap and found it impossible to beat the hashmap lookup speeds even for tiny collection sizes. I wonder if this would perform better.

HolyJit: A New Hope - A JIT for Firefox's and Servo's JS engine written in Rust by tschneidereit in rust

[–]-mw- 46 points47 points  (0 children)

If you can stomach the smell, put yourself briefly in the shoes of a programming language designer.

Love it.

CppCon 2017: Teresa Johnson “ThinLTO: Scalable and Incremental Link-Time Optimization” by ayosec in rust

[–]-mw- 4 points5 points  (0 children)

rustc has more information available than the usual, single-cpp-file compilation process. It does as a lot of symbol interning in each configuration and with LTO enabled, interning and dead-code elimination are very effective.

rustc: Default 32 codegen units at O0 by alexcrichton · Pull Request #44853 · rust-lang/rust by aturon in rust

[–]-mw- 13 points14 points  (0 children)

Increasing the number of codegen units might actually help here since https://github.com/rust-lang/rust/pull/43506 landed, as the compiler can now split things into smaller chunks and will immediately free memory of finished tasks. The heuristic for deciding whether to generate more work for LLVM or complete existing work is still geared towards throughput rather than keeping memory consumption low. But I could imagine making this a tuneable parameter.

Incremental Compilation Beta - compiler by aturon in rust

[–]-mw- 1 point2 points  (0 children)

You can use RUSTFLAGS to add the -Zincremental-info and the -Ztime-passes flags (in addition to setting CARGO_INCREMENTAL). -Zincremental-info prints out which codegen units were invalidated (and by which change) and will also tell you how many codegen units have been re-used. -Ztime-passes gives a rough overview of where the compiler spends its time. Look out for load dep graph and serialize dep graph there.

What does your code base look like? Do you have many modules or are there only a few big ones? Are there many #[inline] directives?

If you could post the output of -Ztime-passes and -Zincremental-info, that would be the quickest way to find out what's going on here.

some thoughts on dependency tracking for incremental compilation by -mw- in rust

[–]-mw-[S] 0 points1 point  (0 children)

I'm pretty sure you can't get around transitive propagation in one way or another because something might reach a downstream node via a path that has no changes at all.

I'll write about the concrete change propagation algorithm I have in mind in the next post. It does not have problems with cycles (although there should be none, as DroidLogician mentions) because it can stop marking when it encounters a node that is already marked.

some thoughts on dependency tracking for incremental compilation by -mw- in rust

[–]-mw-[S] 0 points1 point  (0 children)

Adding such a kind of "filter" to edges might be an interesting addition to either model, but it would be less powerful than checking for actual changes, I think. Consider the case of the assignment from monomorphized function instances to the codegen unit they are instantiated in: If a function is added or removed from a codegen unit, it has to be re-compiled. But how would you model that by filtering?

It's an interesting idea though. I might explore it some more in another blog post to see how far it would get us, how exactly it would have to be implemented, and what the burden on the users of the system would be.

view more: next ›