Thoughts on Rust bloat • Hacker News Board

Re: Thoughts on Rust bloat

#31

Post by dmix » Wed, Aug 21, 2019, 11:14 PM UTC

mapgrep wrote: post #20

>the release binary is now 5.9M A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. This is bloat? I mean, I get it, the binary used to be only 2MB, 1/3rd the size. But are numbers this low really worth worrying about? I think a GUI app in 6MB is hugely impressive. I genuinely thought he was going to say it was 100MB or something higher.

Even Raspberry Pis have many GBs of both disk and RAM and super fast USB, MicroSD, and network transfer speeds.

I don't really see the difference between 5mb and 20mb bins. And I'm a fan of minimalist OS systems like Archlinux with a slim set of running services. Disk space isn't really the main concern besides as a symbolic measure of cruft. No system is ever going to fill up space by having too many OS/terminal programs installed.

But I also don't come from the nostalgic Unixy C programming world. Just a Unix user. So I may be biased.

Re: Thoughts on Rust bloat

#32

Post by carterschonwald » Wed, Aug 21, 2019, 11:15 PM UTC

Seems like a lot of this comes from rust defaulting to allowing several different versions of a library to be linked in ... there’s def some other pieces. But that seems like a biggie

Re: Thoughts on Rust bloat

#33

Post by swsieber » Wed, Aug 21, 2019, 11:16 PM UTC

Qasaur wrote: post #16

vbezhenar wrote: post #13

Earlier quoted context omitted.

Can you do both? Fast compile time and slightly slower execution time for debug build using dynamic dispatch and long compile time and fast execution time for release build using static polymorphism from the same code base.

It could probably be done using conditional builds for which there is support for in cargo, though that would require the programmer to write two versions of the same code. I doubt that it is possible for the compiler to do this optimisation automatically. Recall that dynamic dispatch does not need you as a programmer to know which implementation is being used for a given polymorphic method or function - I find it di…

While the compiker might not be able to do thus optimization automatically, you coukd probably write a proc macro to do it.

Re: Thoughts on Rust bloat

#34

Post by xyzzyz » Wed, Aug 21, 2019, 11:20 PM UTC

mapgrep wrote: post #20

>the release binary is now 5.9M A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. This is bloat? I mean, I get it, the binary used to be only 2MB, 1/3rd the size. But are numbers this low really worth worrying about? I think a GUI app in 6MB is hugely impressive. I genuinely thought he was going to say it was 100MB or something higher.

I think a GUI app in 6MB is hugely impressive.

You think that because nobody cares about bloat anymore, so everything else is large.

Re: Thoughts on Rust bloat

#35

Post by jgibson » Wed, Aug 21, 2019, 11:22 PM UTC

mapgrep wrote: post #20

>the release binary is now 5.9M A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. This is bloat? I mean, I get it, the binary used to be only 2MB, 1/3rd the size. But are numbers this low really worth worrying about? I think a GUI app in 6MB is hugely impressive. I genuinely thought he was going to say it was 100MB or something higher.

It's not just ram that we care about, its all the other CPU caches that are significantly smaller that a larger binary will take up more space in

Re: Thoughts on Rust bloat

#36

Post by _nhynes » Wed, Aug 21, 2019, 11:27 PM UTC

Qasaur wrote: post #6

Use polymorphism sparingly I think it is a little ironic that he speaks of performance culture but simutaneously advises to use dynamic dispatch and avoid polymorphism. I can see the justification in non-critical code paths, but serialisation is a pretty important part of most networked software nowadays so I do not think that smaller binaries and faster compilation times (better developer experience) justifies a per…

When compiling to Wasm (esp. in the context of blockchain), small bytecodes are less costly than fast but short-lived programs.

However, in terms of maintainability, I’m happy to foist a few extra kB of bytecode on developers to produce an idiomatic (i.e. serde-using) library.

Re: Thoughts on Rust bloat

#37

Post by dmix » Wed, Aug 21, 2019, 11:27 PM UTC

weinzierl wrote: post #29

> There’s also an effort to analyze binary sizes more systematically. I applaud such efforts and would love it if they were even more visible. Ideally, crates.io would include some kind of bloat report along with its other metadata, [...] This is what I always wanted (for Rust as well as for C) but never got around to hack together myself. I dreamt it up more as a feature of cargo though, something like 'cargo stats'…

For NPM they should make it optionally inverted to highlight the one line node packages that you can get rid of!

Re: Thoughts on Rust bloat

#38

Post by pcwalton » Wed, Aug 21, 2019, 11:27 PM UTC

ufo wrote: post #27

pcwalton wrote: post #24

Earlier quoted context omitted.

> Also be aware that highly inlined code does nicely in microbenchmarks but might have significantly negative performance implications in a larger system when it blows out the I-cache. I see this assertion a lot, but I have never actually seen a system in which inlining that would otherwise be a win in terms of performance becomes a loss in a large system. LLVM developers seem to agree, because LLVM is quite aggressi…

One somewhat related example I can think of was how the v8 javascript implementation switched from a baseline compiler to a baseline interpreter. The interpreter version has less startup latency (because compiling to bytecode is less work) and uses less RAM (because bytecodes are more compact). It isn't exactly about inling but it is an example where optimizing for size also optimized for speed at the same time.

Good example, but that's not I$ specifically.

Re: Thoughts on Rust bloat

#39

Post by Scuds » Wed, Aug 21, 2019, 11:28 PM UTC

pornel wrote: post #12

It looks like the author is most bothered by compile times of dependencies. Cargo needs to do better with shared caches (so you compile each dep at most once per machine) or ability to get precompiled crates (so you don't even compile it). Incremental improvements of compiler speed or trimming of individual dependencies won't bring the 10x improvement it needs.

Cargo compiles dependencies in parallel so if you have lots of cores you'll hear your fans spin up.

I see a lot of difference between my i5 laptop and i9 desktop.

Re: Thoughts on Rust bloat

#40

Post by ajxs » Wed, Aug 21, 2019, 11:29 PM UTC

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small languages' is very much misplaced. If I can't get through Rust's official documentation without being recommended the use of third party packages for basic functionality (getopt, interfacing with static libraries... Etc) then the designers have made a terrible error.