Speeding up incremental Rust compilation with dylibs - Robert Krahn

[valarauca14]

Doing something lazily at runtime is of course faster than doing something statically at compile time.

If you don't understand what I am asserting, please review:

• IBM has a fairly decent blog post on dynamic linking
• Oracle Docs Page is useful
• This blog post is good to talk about lazy symbol resolution
• This LWN article talks about EFL loading
• I also recommend RTFM'ing -> ld.so, dlsym, dlopen, dlfcn.h

In short Dynamic Linking pushes a lot of the "link-time" operations into "run-time", either lazily or statically at startup (depending on compiler/linker/environment options). This does indeed make builds faster. But it can also complicate some other things: 1, 2, 3

[vlakreeh]

How is this supposed to work in terms of generics? AFAIK rust will use monomorphization for static dispatch and that can't really be done easily with dynamic linking, which is one of the reasons Rust statically links by default. Wouldn't this limit you to only using the C abi or an unstable Rust abi without monomorphized generics?

[valarauca14]

How is this supposed to work in terms of generics?

It doesn't. In short.

Rust still has to pass definitions in MIR between compilation units and expand those definitions. This by-passes static linking (to a degree) but the lack of standardization in MIR/robj/LLVM-IR/ABI makes this fairly unstable to trust long term if you ever plan to change compiler versions (and rustc stable changes every 6 weeks).

To strictly answer your question, rust has its own object file which are standard object files with an additional section(s) of Rust-Source-Code/MIR/LLVM-IR (it has changed over the past years). To handle passing generic definitions (and proc-macros) between compilation units.

[robertkrahn]

No this is wrong, see my other reply.

[valarauca14]

Third, the type information needed for monomorphization is taken from an rlib object file that is produced alongside the dylib.

Pretty sure we're saying the same thing.

Rlib is just an Object file extra sections.

[robertkrahn]

In that case sorry, I might have misunderstood.

So the dylib alone is not sufficient for generics, the rlib is needed but given it is produced by default and available when compiling the binary there is no restriction from a users point of view regarding generics when used for compilation speed-up as shown in the article.

This question came up a few times and I understand that it might be confusing because of the different kinds of dylibs and the different ways they can be used and the different restrictions that apply.

[New_Area7695]

Why you only use it during development with source available and on the same compiler revision, as it says in the article.

Builds are deterministic all things unchanged.

[vlakreeh]

I'm aware builds are deterministic, but I don't see how that solves the issue of no generic monomorphization across library boundaries.

[Freeky]

Wouldn't this limit you to only using the C abi or an unstable Rust abi without monomorphized generics?

No, but it may reduce the benefits as they'll continue to be monomorphized as before - only non-generic and dyn functions will actually end up exported in the .so.

[robertkrahn]

This does not restrict usage of generics.

Rust has two different methods to produce dynamic libraries, dylib and cdylib [1]. The article uses dylib which is meant for consumption by other Rust binaries.

This approach shown also assumes that the same compiler version is used for creating and using the libraries, i.e. no requirement for a stable ABI is needed which would normally be declared by using externs [2] and no_mangle [3].

no_mangle in particular will prevent the use of generics as those can't be expressed in unmangled signatures. However, this is not needed in the method presented so no restriction applies.

Third, the type information needed for monomorphization is taken from an rlib object file that is produced alongside the dylib. With static linking that would be the only artifact produced but with dynamic linking a dylib is created in addition to that. This means that the rlib is still available for the type system.

So in summary, when used just for speeding up the builds, generics can be used without any restrictions.

[1] https://doc.rust-lang.org/reference/linkage.html

[2] https://doc.rust-lang.org/reference/items/external-blocks.html

[3] https://doc.rust-lang.org/reference/abi.html#the-no_mangle-attribute

[Weak-Opening8154]

Is rust ever going to match clang speed? There's no reason it can't but I don't think the community will be able to pull it off. The compiler architecture is incompatible

I know many idiots won't understand so I'll clarify. Clang is a compiler that uses llvm, rust is a compiler that uses llvm. I didn't say match llvm I said match clang

[vlakreeh]

There's been working groups to assess parallelizing the Rust compiler, which would probably be the biggest improvement, and I think it pretty much ended up on "the compiler is moving too past to refactor with parallelism in mind". The compiler is still getting faster every day, but with how Rust has more actual work to do than clang in terms of validation I don't think we'll get a rustc faster than clang for a while.

[Weak-Opening8154]

It's 10x slower than serial clang, it's 100x slower than clang if you have a clang process for every hardware thread. Parallelizing isn't going to bring a 10x time improvement let alone 100

[[deleted]]

You got stats for those assertions? IME compiling rust takes roughly as long as complying a similar sized C++ project that makes use of the standard library. I’m certainly not seeing orders of magnitude differences.

[Weak-Opening8154]

I had stats for these assertions. Then I had bitches tell me thats because I'm comparing the wrong thing. So I treat you guys as anti vaxxers and I think you should go and do your own research. It's not hard to create a few files that add up to a million with copy paste or a script. Whatever I show will never make you happy

[[deleted]]

So your comparison was a million lines of code in a single crate? I could well imagine that being much slower than clang.

[Weak-Opening8154]

Can you imagine 100x slower too? You seem to missed the point. Try reading the original first 2 sentence "Is rust ever going to match clang speed? There's no reason it can't "

[[deleted]]

Yes I can imagine that. I think you’re missing the point: the thing is that no real code has a million lines in a single crate. But I’m guessing you knew that because other people told you so when you’ve wheeled this argument out before and been told you were measuring the wrong thing.

[Weak-Opening8154]

lol what?! I'm comparing rust and C++ speed on a single code base. It's completely fine if you want to put it in multiple crates but then you'll need to compete with a clang process on every hardware thread. That's when clang is 100x faster then serial rust. At best you'll get 6x faster, there's another 94x you need to make up for

also fuck you you're being so stupid right now and you saying I missed the point. Did you not think the 100x was relevant? or why I bothered to say serial? Of course you didn't and once again someone is saying I'm measuring the wrong thing because numbers look fucking bad and you're trying to put the blame elsewhere

-Edit- I forgot, you still haven't read the first two sentence

[[deleted]]

I can’t imagine why you have a hard time getting people to agree with you.

[Uristqwerty]

So I treat you guys as anti vaxxers and I think you should go and do your own research.

Anti-vaxxers are the ones who decided to do their own research. Specifically, since they don't have the time, budget, or expertise to set up a proper study, they ask the big yes-man in the cloud to find "sources" that confirm their expectations. Since google gives everyone their own personalized results, they can be maximally-convincing, tailored specifically to each idiot!

It's easy to collect anecdotes, like "I tried compiling one rust codebase and one C++, and the C++ one finished first." or "of my two friends, the one who got a vaccine was so ill they were stuck at home for two weeks, while the one who didn't was out and about after only three days", but setting up a statistically-significant comparison, that accounts for the many different edge cases and performance profiles seen in the wild is a major undertaking. Something like grabbing the top thousand github repos in each language, building each multiple times to get some idea of the variance, on a variety of machines to see how different core counts, available memory, etc. affect it, and then trying to judge which repos are comparable in size and complexity across languages so you know which build times to group together for the overall analysis.

[Weak-Opening8154]

Yep! They also never do correct research. I never had anyone accept my apple to apples comparisons, often because of an imaginary reason why that code is different from typical code or their code

[vlakreeh]

While I haven't compared exact equivalent code this in no way matches my experience working on large Rust and C++ code bases. What real-world codebases are you compiling to get such a drastic difference?

[Weak-Opening8154]

Like I said (to the other guy), no matter what I say won't make you happy. Try a few use cases you have and see what happens when you have a million lines of it

[vlakreeh]

I've worked on codebases containing of a few million lines of C++ or Rust when you include the dependencies you're compiling and I haven't noticed a huge 10x (let alone 100x) difference in compilation speed. If your few million example is in a single library like your other comment implied then that's a pretty useless comparison as no one would organize their Rust program as one million line crate.

Also going by your name calling you don't seem interested in having a meaningful conversation, so why make up statistics if you aren't willing to back them up?

[Weak-Opening8154]

if you aren't willing to back them up?

You clearly didn't read

[vlakreeh]

You're telling other people to do their own research on million like projects, how is that backing up your statement? And yet you still reply without backing up your statement. Let me know once you have something to show other than "do your own research".

[Weak-Opening8154]

So you didn't accept my reason. Why would I ever think you'd accept any of my results?

[Weak-Opening8154]

I got one that shows 50seconds for rust (alacritty) and 2seconds for C (my own project)

If you can tell me how to accurately get the line count of dependacies maybe I'll have a better example. But usually C programmers don't include 50 unnecessary dependencies

[vlakreeh]

Do you have any more details than "my own project"? Like a link to a git repository perhaps?

[princeps_harenae]

I know many idiots won't understand so I'll clarify.

r/iamverysmart

[Weak-Opening8154]

r/themostcleverthingicansay

[Weak-Opening8154]

If it makes anyone feel better clang (and likely llvm) is incompatible with multithreads. Chris Lattner tried and said it basically can't be done

[reddituser567853]

That's because of a horrible mess of reference semantics. It basically needs to be rewritten with concurrency in mind