Std library inclusion policy, and a data point of compilation times

#21

rustc nightly-x86_64-pc-windows-gnu 1.18.0-nightly (252d3da8a 2017-04-22):

rustc -C opt-level=0 --emit=metadata test.rs: 0.17 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.70 seconds, 186_196 bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.25 seconds, 1_099_576 bytes
rustc test.rs: 0.89 seconds, 1_212_027 bytes
rustc -O test.rs: 1.33 seconds, 1_099_576 bytes

Compilation time is “significantly” decreased (because of https://github.com/rust-lang/rust/pull/41469 ), the binary sizes are a little smaller, and performance benchmarks of other binaries show a small decrease.

5 Likes
#22

The new LLVM is a little slower on my programs, so now the compilation times are back to before pull 4146920. The binaries are a bit smaller, and their performance has shown a relevant increase!

(Some of the performance spots I’d like to see improvements on are u128 division that isn’t inlined, hashing, Bigint of num crate that are slower than Java bigints. Also Rust string don’t cache their hash value, this sometimes causes performance problems).

3 Likes
#23

rustc nightly-x86_64-pc-windows-gnu rustc 1.19.0-nightly (f4209651e 2017-05-05):

rustc -C opt-level=0 --emit=metadata test.rs: 0.21 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.74 seconds, 180_159 bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.28 seconds, 1_087_496 bytes
rustc test.rs: 0.92 seconds, 1_198_847 bytes
rustc -O test.rs: 1.35 seconds, 1_087_496 bytes

The results for this tiny program are consistent with results for other code. The binaries are a little smaller, the run-time is bigger (this means I’ve seen a slowdown of the performance) and the compilation time speedups of 41469 have recently being removed (for this tiny program if I use --emit=metadata the compile time has increased only from 0.17 to 0.21 seconds. For larger programs the time increase is superlinear), in the 2017-05-03 Nightly. I’ve asked for info in the issue 41469 thread.

3 Likes
#24

Thanks for continuing to track this and post updates @leonardo.

cc @nikomatsakis @eddyb just making sure you are seeing @leonardo’s perf updates.

I’m a little surprised we haven’t seen more efforts to create a competitive Rust bignum library.

1 Like
#25

There’s https://github.com/aatch/ramp, FWIW, which tries harder.

1 Like
#26

Is it going to be merged inside the num crate?

I’ve tried to use ramp, and I’m getting many errors like (I am using x86_64-pc-windows-gnu 1.19.0-nightly (e0cc22b4b 2017-05-31)):

error[E0599]: no method named `get_mut` found for type `std::ptr::Unique<ll::limb::Limb>` in the current scope
   --> ...\github.com-1ecc6299db9ec823\ramp-0.3.3\src\int.rs:139:20
    |
139 |             *i.ptr.get_mut() = limb;
    |                    ^^^^^^^

error[E0599]: no method named `get_mut` found for type `std::ptr::Unique<ll::limb::Limb>` in the current scope
   --> ...\github.com-1ecc6299db9ec823\ramp-0.3.3\src\int.rs:153:59
    |
153 |             let mut vec = RawVec::from_raw_parts(self.ptr.get_mut(), old_cap);
    |                                                           ^^^^^^^
1 Like
#27

I don’t know what future the num crate has, and @Aatch has been pretty busy with non-Rust things.

As for those errors - that’s due to recent changes made by @Gankra to those APIs - ramp hasn’t been updated for them.

1 Like
#28

In the last Nightly (GNU Windows) there was a disaster in both compilation times, binary sizes, and run-time of the binary.

1 Like
#29

Perhaps caused by: https://github.com/rust-lang/rust/issues/42808

#30

nightly-x86_64-pc-windows-gnu - V.1.20.0-nightly (622e7e648 2017-06-21):

rustc -C opt-level=0 --emit=metadata test.rs: 0.18 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.90 seconds, 212_677 bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.60 seconds, 1_097_570 bytes
rustc test.rs: 0.94 seconds, 1_230_592 bytes
rustc -O test.rs: 1.56 seconds, 1_096_118 bytes

In other code I’m seeing 8% increase of run-time, and up to about 20% increase of compile-times.

1 Like
#31

I’ve filed a bug report with a small self-contained test program:

1 Like
#32

With the last Nightly the compiler is a little slower, the binaries are a little slower (but one important binary of mine was almost 20% slower) but the biggest difference is in the binary sizes, grown about 220-250%:

nightly-x86_64-pc-windows-gnu 1.21.0-nightly (c11f689d2 2017-08-29):

rustc -C opt-level=0 --emit=metadata test.rs: 0.18 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.97 seconds, 291_973 bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.66 seconds, 2_744_288 bytes
rustc test.rs: 1.07 seconds, 2_881_133 bytes
rustc -O test.rs: 1.65 seconds, 2_743_776 bytes
2 Likes
#33

Looks like a bug to me! Have you opened an issue?

#34

Not yet. Currently discussing the problem on IRC…

Update: apparently the problem is not visible in the msvc and Linux64 targets. I’ve seen it on the gnu64 target. Is someone willing and able to test it on the gnu32 target?

https://github.com/rust-lang/rust/issues/44183

#35

In my code since the 1.24.0-nightly 2017-12-15 I’m seeing about 20-22% increase of compilation times using --emit=metadata (and I am using less than 30 constants), and more than 5% performance decrease of the binary. And every day since (2017-12-16 and 2017-12-17) things are getting a little worse. Alarm! :slight_smile:

4 Likes
#36

Ouch! That sounds pretty bad. Should post on this on the internals list perhaps?

#37

First I’ll try to better pinpoint where the problems are…

2 Likes
#38

Sounds good :slight_smile:

#39

I’ve opened a bug report, the whole deal took me more time than expected:

4 Likes
#40

In the bug report comments arielb1i is asking if someone is able & willing to reproduce the problem on other hosts.