- cargo and optimizations (acrichto)
- zero^H^H^H^Hfilling drop (pnkfelix)
- type ascription (nrc)
pnkfelix, brson, pcwalton, larsberg, nmatsakis, steveklabnik, acrichto, nrc
acrichto: stabilizing std::{io, net, fs, ffi} + str unicode brson: cargo global CI
- acrichto: print "(debug)" and change output directory of
cargo build
Manish started working on Servo as part of the GSoC program in 2014, where he implemented XMLHttpRequest. Since then he's become in integral part of the Servo team while finishing his university studies and organizing Rust community events. In 2015 he took an interest in bors' queue and started making rollup PRs to accelerate the integration process. Nursing the PR queue is the kind of time-consuming labor that creates friends of the tree like Manish, the rollup friend of the tree.
- acrichto: Wanted to talk about some of the defaults, including optimization. In general, it's a footgun that we don't optimize code by default. About once a week, somebody posts about Rust's slow performance because they didn't do
cargo build --release. The idea is that this is so bad that we should do something. Extreme: optimize by default. Maybe not in the compiler, but cargo. Possibly dependencies but not the main crate? Or print "debug build". - nmatsakis: "Non-optimized" build, in particular.
- nrc: Why do you think it's not a good idea to optimize by default?
- acrichto: Build times are really slow. When using Cargo, I want a developer-optimized default. I know as a developer that I should switch when I want to profile. So it's nice to have a debug build by default...
- nmatsakis: One comment is that it would surprise me if optimizations were on by default. Also, has anybody looked at the combinations of settings to see if there's a better intermediate setting?
- pcwalton: There were experiments 2 or 3 years ago, but they're very out of date now.
- nmatsakis: For example, in a disable-optimize build, coherence went from 5 seconds to 200. (ed. -- but I should retest this, maybe I was running something in the background)
- acrichto: Cargo doesn't help here. Optimized and unoptimized are the only points in the spectrum.
- nrc: I feel debug by default for rustc is great, since that's what C compilers do. Cargo is meant to be more of an "it just works experience" like Ruby/JS where you never think about it. The standard build is what you send to the customer. Like it's a compiler for people who don't care about options...
- pcwalton: I disagree. Tried & true is just to change "compiling" to "compiling (Debug)" or "compiling (Release)". Have also seen makefiles do things that are similar. That's the precedent. With compiled languages, pretty much all (except go) do not optimize by default. Ruby and JS aren't a good precedent for us. Even Java needs
-Xserver. If we go to optimizing by default, we just move from one set of problems to the other. I suspect that if we change the default to optimized, people will stop complaining about benchmark performance but instead will complain about compile times. Also, release builds lose debugging and profiling support. - nmatsakis: The Gecko makefiles build release by default.
- nrc: Shouldn't think of cargo like a compiler, but like a build system.
- steve: I tweeted about this. Most people said they expect to have to opt out of optimizations from their build system, not opt into them. (tweet: https://twitter.com/steveklabnik/status/572451589644009472 reddit thread: http://www.reddit.com/r/programming/comments/2xnlv7/3d_voxel_renderer_using_raytracing_written_in_rust/cp1zfi6 )
- pcwalton: I don't know what IDE they're using, but XCode is debug by default. And it's hard to figure out how to even switch to release builds.
- pnkfelix: What do most configure scripts do?
- nmatsakis: I think that's what's under debate. Whatever we do, we should highlight in bold print
- larsberg: Doesn't help that the debug binaries are not in a debug directory.
- pcwalton: Definitely! That will break stuff.
- acrichto: Maybe we could have target/foo symlink to the new one... maybe nuke it and just use flavor-specific builds.
- pcwalton: This would probably solve the problem of dumb benchmarks even just saying the output. But having target/debug and target/release would be best.
- nrc: Custom target directories at the same time would be great! I hate having a target directory named target...
- acrichto: Sounds like I'll change the output for debug vs. release to bold. Also, instead create a debug directory next to the release directory. Leave debug as the default.
- pcwalton: Definitely. It's a conservative approach, and we could change later.
- pnkfelix: If we change to optimized by default, we need to reconsider the codegen defaults. Stuff like overflow was designed in the context of debug-as-default.
- pnkfelix: I'm going to write something up, but the problem is that we've been planning to have non-zeroing dynamic drop. It could, but probably won't happen for 1.0. It's a huge risk in terms of clients depending on the non-zeroing behavior. So, why not flip the bits so that it's a zero to start and fill it with a 1 when we "zero" it, which would discourage people from relying on the data in it.
- pcwalton: Sounds good, but should measure code bloat. On x86, it's much smaller to zero instead of filling with a value, but I doubt it'll matter much. Worth checking, though I doubt it.
- pnkfelix: We were debating this earlier and whether it should be under a -Z flag, but I want to just do it and see what happens. It's got about 70 failing tests, but is close to ready.
- pcwalton: As I recall, MSVC does something similar. 0xCD for heap; 0xCA for stack. Maybe follow those conventions?
- pnkfelix: I've been looking into it.
- brson: Most likely outcome for people who rely on this is that they'll see crashes?
- pnkfelix: Yes.
- brson: So they will see them, right? Not do something they won't catch?
- pcwalton: That's why you use a weird bit pattern. It's unlikely that a pattern like that is valid.
- pnkfelix: It's mainly people who are doing unsafe code and doing weird things in their destructors. Current plan is not just to tests for nonzero, but for the particular byte pattern. If it's neither of the ones I expect, you get a debug interrupt. If I leave it like that, it's code bloat, but it's hugely valuable to see that you've broken an invariant.
- pcwalton: Only one byte on x86. LLVM leaves in debug traps in some things where they could remove them because the code bloat was minimal (e.g., null pointers).
- nmatsakis: clearly we should consult http://www.nsftools.com/tips/HexWords.htm
- pcwalton: Should measure, but I think it's cheap on x86. Also, don't get too cute with words - you will bloat the instruction stream.
- acrichto: Can be some subtle breakage, since the pointer type of the compiler is not safe against zeroing. Some problems will be discovered immediately, but some of them will not. This change may manifest in a crash at runtime...
- nmatsakis: This change is at least a way to split the not-zeroing work from fixing bugs.
- pnkfelix: I'll write something up for internals.
- nrc: There's an RFC. I want to get our coersion story 100% solid because there are back compat problems there. New proposal is that all kinds of unnecessary casts (except numeric) would be linted together and warn-by-default. Customizable per crate. That's the important bit from that RFC. As for type ascription itself, I think it's something we want, but not great impetus to do so before 1.0. That said, it's pretty much ready to go. Minor payout, but also minor work. The other motivation for this work is that eddyb wants to use this to get rid of integer suffixes. Might be too late for this, though if we did want to do that, we need to land type ascription. Thoughts?
- pcwalton: Integer suffixes are pretty harmless.
- nmatsakis: I don't care about the suffixes. I feel pretty good about the RFC. OK with leaving it feature gated for now. Seems reasonable. Maybe we'll find a syntax we like better. The RFC is still limited to expressions?
- nrc: Yes.
- steve: I like suffixes.
- nrc: Might be a problem because they're nearly always the type. So, you can always write
: blahinstead ofblahanywhere. - steve: Might be because I'm from Ruby and don't mind multiple ways to write them.
- pnkfelix: Like underscores; I like multiple ways to write integer literals.
- nmatsakis: We're not removing suffixes. Question is just whether we land this or not, and if so, with what status. Does having a feature gate feel better than adding this feature?
- brson: I was just not excited about adding this so late in the game with this timing. But since we have to do this eventually and we have a design, I'm not really opposed.
- nmatsakis: I prefer to land this gated because it's our policy. Especially since there was significant opposition & feedback around the syntax. I don't know what else we would ever use, though.
- brson: No opposition to ascription the feature, though, right?
- nmatsakis: Yes.
- nrc: Certainly, in the thread.
- steve: As long as it doesn't ruin struct syntax, I'm OK with it.
- brson: Let's do it, then.
- nrc: I'll update the RFC with the latest. So, people are OK with unnecessary casts to be warn by default, with different ones for numerics vs. non-numeric?
- acrichto: I'll read it in more detail.
- nrc: RFC states there are three lints. Squash two of them together, but keep the numeric one separate. The motivation was for platform-specific stuff, which is sometimes widening and sometimes not.
- acrichto: I like that.
- nrc: I'll update the RFC and ping someone for merge.