[HN Gopher] This isn't the way to speed up Rust compile times
___________________________________________________________________
This isn't the way to speed up Rust compile times
Author : cpach
Score : 63 points
Date : 2023-08-26 12:55 UTC (10 hours ago)
(HTM) web link (xeiaso.net)
(TXT) w3m dump (xeiaso.net)
| lamontcg wrote:
| > However, this means that the most commonly used crate is
| shipping an arbitrary binary for production builds without any
| way to opt-out.
|
| The nokogiri rubygem has been shipping a prebuilt windows dll for
| probably more than a decade. The sun has not imploded into a
| black hole at any point in the meantime.
|
| > If we're going to be trusting some random guy's binaries, I
| think we are in the right to demand that it is byte-for-byte
| reproducible on commodity hardware without having to reverse-
| engineer the build process and figure out which nightly version
| of the compiler is being used to compile this binary blob that
| will be run everywhere.
|
| I have some really, really fucking bad news about the O/S distros
| most of you all use...
| yw3410 wrote:
| The author uses NixOS.
| lamontcg wrote:
| "Most of you all", addressing the HN audience, not the
| author.
| whatisyour wrote:
| most distros are moving towards reproducible builds.
| chungy wrote:
| Debian and Fedora have likewise both been pushing
| reproducible builds.
| lamontcg wrote:
| I used to use a FreeBSD desktop at work back in like 2002.
|
| And that is a reasonable thing for those projects to try to
| achieve.
|
| Still we've been downloading binaries for decades and the
| world hasn't ended, this issue never warranted people
| treating it like nuclear war was imminent and hurling abuse
| into Dtolnay's github issues like he was a child
| pornographer. There's a way to have a discussion about this
| being the wrong direction without doing that.
|
| And I'd encourage everyone to take an honest audit of how
| many precompiled binaries are in their lives, even if
| they've switched to NixOS and how much stuff they trust
| downloading from the internet. Very few people achieve an
| RMS-level of purity in their technological lives.
| jacquesm wrote:
| This is all true, but even if you don't care about
| reproducible builds that doesn't mean that _nobody_ cares
| about reproducible builds. And the people that do care
| about such things care about them very much. To the point
| that if you don 't offer it to them that they'll go
| somewhere else.
| lamontcg wrote:
| I didn't say not to try to get to reproducible builds,
| though, but not to treat Dtolnay like he's a criminal.
|
| There is a very real problem that he was trying to solve,
| but the right way to do it will require core language
| support. And his heart is certainly in the right place,
| since "slow build times" is probably the #1 complaint
| about Rust.
|
| If you actually polled most Rust users they probably care
| about their build times more than they care about this
| issue, particularly if you designed the survey
| impartially and just asked them to stack rank priorities.
| They probably all would prefer "both" being the right
| answer though.
|
| Where the criticism really needs to be leveled is on the
| core language design (although I appreciate that their
| job is also extremely tough).
|
| [And the one good thing to come out of this shitshow will
| probably be getting people focused on solving this issue
| the right way]
| jacquesm wrote:
| It's funny how opposed the 'Go' and 'Rust' eco systems
| are, the 'Go' people optimized for compile speed from day
| 1 but have trouble making things safe, the 'Rust' people
| optimized for safety from day 1 but have trouble making
| things fast.
|
| Maybe they could learn a trick or two from each other?
| _gabe_ wrote:
| I don't program in Go, but this is the first I've heard
| of it being unsafe. I thought Go was a GC language
| implemented via the Go runtime and properly handles
| memory safety (memory corruption and OOB access). Are you
| using a different definition of safety here or is there
| something else that I'm not aware of?
| suby wrote:
| The world hasn't ended, but I'd argue that the number of
| malicious actors within the space is rising, as are the
| consequences of being compromised. We're simply seeing
| more and more malware make its way into open source
| ecosystems, and I don't imagine the trend will be
| reversing. For this reason alone we should be striving to
| achieve full build reproducibility, though I agree with
| you that demonizing (or threatening) Dtolnay is wildly
| inappropriate.
| ptx wrote:
| With a distro we're trusting a single trustworthy source for
| all the software, whereas with package managers for most
| programming languages we're trusting hundreds of individual
| developers, any one of which can suddenly decide to sell us
| out.
| alphanullmeric wrote:
| The issue is the reliance on macros in the first place, which
| half the time are just a shitty substitute for overloading,
| variadics and inheritance that can't be nested, doesn't have
| editor highlighting, and takes longer to compile. Macros should
| be a last resort and not a first resort, "rust macros are better"
| isn't a good counter argument. Rust's big government philosophy
| of forcing design choices onto the programmer yet again comes
| back to bite it.
| pie_flavor wrote:
| Please describe how you would implement the functionality of
| the serde::Serialize macro with overloading, variadics, and
| inheritance.
| alphanullmeric wrote:
| I'm referring to things like println, which isn't a macro in
| any other language. If you want to stick with the serde
| example, then look at the diy name mangling in the
| deserializer trait:
|
| https://docs.rs/serde/latest/serde/trait.Deserializer.html
|
| Or the copy and pasting in Axum:
|
| https://github.com/tokio-
| rs/axum/blob/24f0f3eae8054c7a495cd3...
| nightfly wrote:
| Println is also much more complicated and expensive at
| runtime in "any other language"
| alphanullmeric wrote:
| Except for C++.
| pie_flavor wrote:
| You mean the language which, in every major
| implementation, that particular function is a _macro?_
| alphanullmeric wrote:
| What macro?
|
| https://en.cppreference.com/w/cpp/io/print
| plorkyeran wrote:
| None of printf, iostreams, or std::fmt are macros in any
| implementation I'm aware of.
| pie_flavor wrote:
| va_arg, which drives printf, is what I was referring to,
| and is generally a macro, and printf is what I was
| assuming alphanullmeric was referring to. iostreams
| defeat the point, since Rust is just as capable of the
| functionality and indeed the exact syntax, and
| std::format uses the properties of templates that are
| exactly like macros in both benefits and drawbacks,
| templates being an unusual cross between macros and
| generics.
| SkiFire13 wrote:
| I'm failing to see how this is relevant then. You say the
| issue is with macros in the first place, but then it turns
| out you're actually referring to other macros and have no
| alternative to the macro that actually created the problem.
| What am I missing in your reasoning?
| alphanullmeric wrote:
| The issue is with macros in general, and the problem is
| present with macros in general, even if there's no better
| solution in this specific case. If someone is willing to
| take such drastic measures to combat the downsides of
| macros when they are needed, what would they be willing
| to do when they're forced to use macros when they
| shouldn't be needed?
| pie_flavor wrote:
| The drastic measure is because of the large amount of
| code serde generates. The features you describe, by
| contrast, do not involve much code from a macro
| standpoint and such macros would not benefit from
| precompilation.
|
| If you're complaining about something that TFA is not an
| example of, it's a good idea to at least provide
| something that _is_ an example of it, because otherwise
| you 're just yelling at clouds.
| [deleted]
| say_it_as_it_is wrote:
| [flagged]
| dang wrote:
| Please don't do this here.
| titaniumtown wrote:
| very different format to the blog with different characters
| chiming in. interesting!
| DisgracePlacard wrote:
| > If we're going to be trusting some random guy's binaries, I
| think we are in the right to demand that it is byte-for-byte
| reproducible on commodity hardware
|
| I don't think anyone has a right to demand _anything_ of the
| project. The MIT license specifically has the whole "THIS
| SOFTWARE IS PROVIDED AS IS" spiel for a reason. Thinking that you
| can demand anything of an open source developer who, afaik, has
| no responsibilities in relationship towards you, is a rather
| toxic mindset that should be kept out of open source.
| pessimizer wrote:
| The demands are provided "as is," too, so you have no right to
| complain about them.
| saagarjha wrote:
| That's not true. I can, for example, demand that an open source
| project not bundle malware. The maintainer may not listen to me
| but I reserve the right to demand it and I don't see how this
| is toxic at all.
| pie_flavor wrote:
| If you skipped over the header, like I did originally, it bears
| repeating: This change was reverted a couple days ago.
| phamilton wrote:
| The Pre-RFC that came out of this situation is pretty
| interesting: https://internals.rust-lang.org/t/pre-rfc-sandboxed-
| determin...
|
| Some points I hadn't considered:
|
| - Current compile times aren't too bad, but compile times are a
| factor in how macros are developed. Making that less of an issue
| will likely make the macro ecosystem richer and more ambitious.
|
| - Precompiled binaries can be compiled with optimizations, which
| anecdotally overcome the potential perf hit from running in WASM
|
| - Nondeterminism in macros (especially randomness) has bit a lot
| of people and a more controlled execution environment is very
| beneficial
|
| - Sandboxing doesn't have to be WASM, it's just the most capable,
| currently available option.
|
| - Comments on the pre-RFC are exploring solving this in
| rustup/cargo instead of crates.io and that is also promising.
|
| In general, I appreciate how this is creating awareness and
| driving exploration of solutions. In particular I really like the
| notion that there is currently implicit pressure on macro authors
| to make them somewhat quick to compile and releasing that
| pressure will enable innovation.
| jeremyjh wrote:
| Nothing personal Cadey, but I don't want to see your ads, or
| anyone else's, regardless of how "ethical" they are. Even if they
| are not tracking me (which I cannot confirm) they are
| manipulating me. I found your message confusing, I thought it was
| part of the article at first. Maybe pop that up unobtrusively if
| you've seen me a few times before, or after I've been reading a
| few minutes.
| nightfly wrote:
| What ad are you talking about?
| jeremyjh wrote:
| If you have an ad-blocker enabled, the first paragraph of the
| page asks you to turn it off or donate. I have no problem
| with creators being compensated for their work, or asking for
| that compensation, but I found it confusing.
| dang wrote:
| " _Please don 't pick the most provocative thing in an article
| or post to complain about in the thread. Find something
| interesting to respond to instead._"
|
| " _Please don 't complain about tangential annoyances--e.g.
| article or website formats, name collisions, or back-button
| breakage. They're too common to be interesting._"
|
| https://news.ycombinator.com/newsguidelines.html
| galkk wrote:
| Totally unrelated.
|
| But generated picture at the beginning of the article, the one
| with space needle, robs me very wrong way, as real landscape
| doesn't look like it. It's like seeing Golden Gate Bridge in New
| York.
| xena wrote:
| Author here. Yeah, the model I use (Anything v3) has a really
| weird way of generating the Space Needle in particular. I'm
| originally from Seattle and I really miss the pacific
| northwest, so I like to put the Space Needle in my AI
| generations because of how much it can stick out or clash with
| the rest of the image.
|
| In the future I'm gonna use more of my own photography like
| this: https://pony.social/@cadey/110956174300162810, I'm just
| building up a library of viable photos.
| scubbo wrote:
| What's the story behind "-amputee" in the arguments? Were
| such images so common that it was necessary to exclude them!?
| galkk wrote:
| So in this case it did work as intended :)
| KolmogorovComp wrote:
| Note that the pre-compiled binary blob the blog post is referring
| to has since been removed [0].
|
| [0]: https://github.com/serde-rs/serde/pull/2590
| xena wrote:
| I thought I made that pretty clear in my article. Do I need to
| bring back the blink tag or something to make it more obvious
| in the future?
| KolmogorovComp wrote:
| I indeed missed the header, as other readers hear. I'd advise
| against using the characters' bubbles to provide important
| heads-up, as they're often used for additional insights or
| humorous opinion, and so can be easily missed by quick
| readers.
| gpm wrote:
| I missed it because the header to me looks like
|
| > Something about ads
|
| > Title
|
| > Something I skipped
|
| > Something about patreon
|
| I dismissed it as "yet another part of the headers" and not
| as "part of the article".
|
| I mean, to be fair, I was already aware it was removed from
| serde, but I'm pretty sure I didn't notice that box in the
| article the first time I read through it.
| capableweb wrote:
| The top of the article looks like a screenshot of a chat,
| where someone said something, then some text and then the
| same person said something. I basically skipped that whole
| part to look for the article beginning, and when I didn't
| find the title, I skimmed back up.
|
| The title is kind of hidden as it is right now, and the
| "notice" on the top doesn't look like a notice. Maybe try
| making it more different than other elements on the website,
| and put it below the article title rather than above?
| brigadier132 wrote:
| I know a lot of people feel very strongly about this thing and
| thankfully Dtolnay reversed course but if there is anyone out
| there that has social media mob mentality please don't harass
| him. A lot of the packages I use have his name associated with
| them and if we get the classic "I'm leaving open source because
| of the toxicity" and he is the author the rust community will be
| screwed.
| rewmie wrote:
| Let's see if the Rust community learned anything from the
| actix-web fiasco.
| Dowwie wrote:
| Rage blogging is never by contributors
| [deleted]
| Guvante wrote:
| In case anyone missed the first line like I did this has been
| resolved and no longer works like this.
| jamamp wrote:
| Swift's `Codable`[0] system seems very similar to serde in this
| regard. Structs that you define can be marked with the Codable
| protocol, and the Swift compiler automatically generates code
| during compilation that encodes from and decodes to the structs
| properties, with the option for you to customize it using
| CodingKeys for different properties names or completely custom
| coding behavior.
|
| It seems built-in to Swift, as opposed to a dynamically executed
| crate like with serde. I wonder how it's implemented in Swift and
| if it leads to any significant slowdowns.
|
| [0]
| https://developer.apple.com/documentation/foundation/archive...
| itaiferber wrote:
| Codable (along with other derived conformances like Equatable,
| Hashable, and RawRepresentable) is indeed built in to the
| compiler[0], but unlike Serde, it operates during type-checking
| on a fully-constructed AST (with access to type information),
| manipulating the AST to insert code. Because it operates at a
| later stage of compilation and at a much higher level (with
| access to type information), the work necessary is
| significantly less. (It's difficult to compare Serde and
| Codable in a way that isn't apples-and-oranges, but at the very
| least, Codable makes use of information that the compiler has
| done, and has already needed to do anyway; there's very little
| manipulation it needs to do to achieve its aims.)
|
| With ongoing work for Swift macros, it may eventually be
| possible to rip this code out of the compiler and rewrite it as
| a macro, though it would need to be a semantic macro[1] rather
| a syntactic one, which isn't currently possible in Swift[2].
|
| [0]
| https://github.com/apple/swift/blob/main/lib/Sema/DerivedCon...
| [1]
| https://gist.github.com/DougGregor/4f3ba5f4eadac474ae62eae83...
| [2] https://forums.swift.org/t/why-arent-macros-given-type-
| infor...
| raphlinus wrote:
| Last I checked[1], Swift JSON performance was terrible, well
| over an order of magnitude slower than serde. It's possible
| it's been improved since then but if so I didn't find any
| announcement.
|
| [1]: https://github.com/xi-editor/xi-mac/issues/102
| viktorcode wrote:
| The problem wasn't Swift Codable, the problem was Apple's
| implementation of JSONEncoder / Decoder on top of Obj-C
| runtime, which created unnecessary round trips.
|
| It was only fully addressed in Swift 5.9.
| plorkyeran wrote:
| Both are problems, and it's far from fully addressed in
| Swift 5.9. The new Swift implementation of JSONEncoding is
| "only" 2-5x faster than the old one, so while it's a big
| improvement it's still very slow. Codable itself is also
| very performance-hostile, and a no-op encoder which fully
| walks the input but doesn't produce any output will be
| slower than serde producing json.
| dundarious wrote:
| On topic: I agree that upstream-provided 3rd party binaries are
| not a good solution to this particular problem. That is the type
| of solution that works in a closed environment like a corporate
| CI system, but it should not be the default.
|
| Off topic: I don't understand why the article repeatedly says the
| Rust compiler or procedural macros are already fast, even "plenty
| fast". Aren't they slower or about as slow as C++, which is
| notorious for being frustratingly slow, _especially_ for local,
| non-distributed builds?
|
| "Plenty fast" would mean fast enough for some simple use-case.
| e.g., "1G ethernet is plenty fast for a home network, but data
| centers can definitely benefit from faster links". i.e., fast
| enough you won't notice anything faster when doing your average
| user's daily activities, but certainly not fast enough for all
| users or activities.
|
| The Rust compiler is then in no way "plenty fast". It has many
| benefits, and lots of hard work has gone into it, even optimizing
| it, but everyone would notice and benefit from it being any
| amount faster.
| rewmie wrote:
| > On topic: I agree that 3rd party binaries are not a good
| solution to this particular problem. That is the type of
| solution that works in a closed environment like a corporate CI
| system, but it should not be the default.
|
| Why?
|
| I mean, OS distributions making available whole catalogs of
| prebuilt binaries is a time-tested solution solution that's in
| place for decades. What leads you to believe that this is
| suddenly undesirable?
| dundarious wrote:
| I think there's a very obvious distinction between the kind
| of "3rd party" that is your chosen OS distribution and the
| kind of 3rd party that is "some person on github or
| crates.io", and I didn't feel the need to clarify this as I
| thought it was obvious.
|
| I've clarified it to "upstream-provided 3rd party" in the
| original post.
| rewmie wrote:
| > I think there's a very obvious distinction between the
| kind of "3rd party" that is your chosen OS distribution and
| the kind of 3rd party that is "some person on github or
| crates.io"
|
| That tells you more about crates.io than consuming prebuilt
| binaries.
|
| Some Linux distro ship both source code packages and
| prebuilt binaries. This has not been a problem for the past
| two decades. Why is it suddenly a problem with Rust's
| ecosystem?
| tyg13 wrote:
| crates.io is just a platform for people to make their
| Rust code distributable; it's not curated in any way
| really (other than removing obvious malware). An OS
| distribution is explicitly curated.
| formerly_proven wrote:
| Either way you're running their code, I don't understand
| the outrage here, frankly. People who look at the code
| they're running and the changes they're pulling in of
| course noticed this, but I seriously doubt even 1% of the
| rageposters are in that set of rust users.
| dundarious wrote:
| I'm not outraged. I dislike it, and it would be a "con"
| when considering any use of the project.
|
| Binaries are relatively inscrutable, and there are
| massive differences in ease of doing something nefarious
| or careless with OS binaries, and upstream checked in
| source code, and upstream checked in binaries.
|
| That's just one or two reasons why I think this approach
| is not at all commonplace in open settings, and is
| generally limited to closed and controlled settings like
| corporate environments.
|
| A more typical and reasonable approach would be having a
| dependency on such a binary that you get however you
| like: OS, build from upstream source, upstream binary,
| etc., and where the default is not the latter.
|
| And now if you allow me to get a bit off-topic again: to
| me, having to "innovate" like this is a major sign that
| this project knows it is very slow, and knows it's
| unlikely to ever not be very slow.
| bsder wrote:
| Because it demonstrates a failure of the Rust ecosystem.
|
| Proc macros have effectively become fundamental to Rust. This
| is unfortunate, but, given that it is reality, they should
| get compiler support. Part of what is making them so slow is
| that they need to process a firehose of information through a
| drinking straw. Placing proc macros into the compiler would
| not only speed them up but also remove the 50+ crate
| dependency chain that gets pulled in.
|
| Serde, while slow, has a more fundamental Rust problem. Serde
| demonstrates that Rust needs some more abstractions that it
| currently does not have. The "orphan rule" means that you,
| dear user, cannot take my crate and Serde and compose them
| without a large amount of copypasta boilerplate. A better
| composition story would speed up the compilation of Serde as
| it would have to do far less work.
|
| Rust has fundamental problems to solve, and lately only seems
| capable of stopgaps instead of progress. This is unfortunate
| as it will wind up ceding the field to something like Carbon.
| maccard wrote:
| > Aren't they slower or about as slow as C++, which is
| notorious for being frustratingly slow, especially for local,
| non-distributed builds?
|
| Yes. Significantly slower. The last rust crate I pulled [0]
| took as long to build as the unreal engine project I work on.
|
| [0] https://github.com/getsentry/symbolicator/
| rascul wrote:
| I was curious about a couple numbers. Looks like symbolicator
| has about 20k lines of rust code and 517 crates it depends on
| (directly and indirectly).
| forrestthewoods wrote:
| Ehhhhhhhh. Are you talking full build or incremental? How
| long did it take?
|
| Clean and rebuild of Unreal Engine on my 32-core Threadripper
| takes about 15 minutes. And incremental change to a CPP
| takes... varies but probably on the order of 30 seconds.
| Their live coding feature is super slick.
|
| I just cloned, downloaded dependencies, and fully built
| Symbolicator in 3 minutes 15 seconds. A quick incremental
| change and build tool 45 seconds.
|
| My impression is the Rust time was all spent linking. Some
| big company desperately needs to spend the time to port Mold
| linker to Windows. Supposedly Microsoft is working on a
| faster linker. But I think it'd be better to just port Mold.
| IAmLiterallyAB wrote:
| Mold is ELF only. They'd have to rewrite it anyway. I don't
| see much point in a Windows port
| forrestthewoods wrote:
| It's tentatively planned for 3.0.
| https://github.com/bluewhalesystems/sold/issues/8
|
| The file formats are indeed totally different. But the
| operation of linking is the same at a high-level.
| IAmLiterallyAB wrote:
| Huh, interesting
| maccard wrote:
| My 32 core threadripper builds ue5 in 12 minutes on
| Windows. Single file changes on our game are usually under
| 10 seconds due to unity builds, and a good precompiled
| header.
|
| My first clone on symbolicator took the same length of time
| on my windows machine. Even with your numbers, 4 minutes to
| build what is not a particularly large project is bonkers.
| I
| forrestthewoods wrote:
| Sounds like we're on basically the same page.
|
| My experience across a wide range of C++ projects and
| wide range of Rust projects is that they're roughly
| comparable in terms of compilation speed. Rust macros can
| do bad things very quickly. Same as C++ templates.
|
| Meanwhile I have some CUDA targets that take over 5
| minutes to compile a single file.
|
| I feel like if Rust got a super fast incremental linker
| it'd be in a pretty decent place.
| izacus wrote:
| Is using a 32-core CPU as a baseline for speed
| comparisons some kind of satire in this thread?
| delusional wrote:
| I think there's a different kind of "plenty fast" that more
| closely aligns with "as fast as it can be." If you develop some
| code that runs at 90% of the theoretical throughput, I'd call
| that plenty fast, even if the theoretical wait time was 100s of
| seconds. The rust compiler does a lot of stuff that simpler
| languages don't do. I would accept that level of checking to
| take longer while still being considered "plenty fast". Making
| that argument would require some serious benchmarking of the
| rust compiler though.
| incrudible wrote:
| I like the Go style better. I probably will not ever care about
| more than one or two encodings and being explicit is an upside in
| that regard. I do however really care about compile times. If
| performance really matters, I would not go for a generic
| serialization approach in the first place.
| charcircuit wrote:
| >If we're going to be trusting some random guy's binaries, I
| think we are in the right to demand that it is byte-for-byte
| reproducible on commodity hardware without having to reverse-
| engineer the build process and figure out which nightly version
| of the compiler is being used to compile this binary blob that
| will be run everywhere.
|
| David Tolnay is not a random guy.
| CUViper wrote:
| Then extrapolate "random guy trying to follow dtolnay's lead."
| IshKebab wrote:
| Well then complain about _that_ , not this.
|
| And anyway it doesn't really matter. As soon as you use
| anyone's crates you're more or less completely trusting them.
| It's not difficult to hide malware in a Rust crate even if
| you don't ship a binary.
|
| And... come on. David Tolnay came up with Watt. He's clearly
| not intending to ship a binary forever - the long term
| solution is WASM.
|
| This author comes across as an annoying naysayer - everything
| is impossible, even things that have already been done like
| WASI.
| badrequest wrote:
| [flagged]
| [deleted]
___________________________________________________________________
(page generated 2023-08-26 23:01 UTC)