forked from rust-lang/rust
Meeting weekly 2012 03 20
dherman edited this page Mar 20, 2012
·
1 revision
Brian, Graydon, Jesse, Dave, Niko, Patrick, Tim, Marijn
- Niko: still no agenda in advance; any issues?
- Marijn: I have some
- Patrick: I have some
- Marijn: RFC today for argument modes -- everyone agrees they're not a great thing; with mono we can get rid of by-val / by-ref distinction; something like by-copy will remain needed; saves a lot of copies from constructor functions, mostly enums; unless someone has alternative, should keep at least two modes
- Graydon: which two?
- Patrick: not sure I totally understand problem. could you explain?
- Marijn: everyone understand by-copy?
- Niko: explain anyway?
- Marijn: says "this function needs to own argument"
- Jesse: two modes are really "with ownership" and "without ownership"; caller can decide whether copying or moving
- Niko: not a big fan of keeping copy mode; creates implicit copies
- Marijn: it removes implicit copies as it currently is
- Niko: in one sense, yeah; but I'd like to think about this a little bit; not sure why we need it per se; I'd like to see how regions turn out
- Marijn: I don't think regions are relevant; say you want to call enum ctor with something big (some(vec)) -- explicitly at caller site annotate as move
- Niko: disagree; pass it by-value, which means ownership
- Marijn: by-value is by-copy essentially
- Niko: maybe we should just have by-value period; when you pass a pointer by value that's cheap
- Marijn: so a function would always own its arguments
- Niko: always, yeah
- Marijn: ampersands will be a pain
- Graydon: winds up looking like C; actually okay with that; semantics much better understood; I know there are a lot of ampersands (asterisks in C), but I think systems people are comfortable with that
- Patrick: I agree with Graydon; I'd love to eliminate by-pointer/by-value
- Niko: I think I agree with Graydon as well
- Marijn: if that works out, we can drop argument modes altogether; that would of course be very desirable; let's try
- Marijn: other thing: troubleshooting thing: pushed patch to make lots of symbols internal to our libraries; decreased speed; anyone have an idea why that might be?
- Niko: is check to decide what's internal/external expensive?
- Marijn: if I change code to only remove lines that call setVisibility then slowness goes away
- Patrick: internal vs external makes LLVM optimizations totally different; think it optimizes internal much better
- Marijn: doesn't show up in unoptimized build, so plausible
- Niko: sounds like a good patch then
- Marijn: agree
- Patrick: only for optimized builds; shouldn't treat regressions in optimized builds as seriously
- Niko: agree
- Graydon: release status: want to try try try to get release package going; profiler I've been working on probably won't land; some spooky bugs and not critical; will try to get x64 ABI fix done; but then hoping to package by the end of the week or early next; okay?
- Niko: great
- Graydon: I did make a new profiler, in a branch in my private repo; fair amount of interesting info on where we're spending instr counts; if anyone wants to do perf hunting contact me, I'll show you how to use it
- Graydon: failed to mention a while ago: we got an invite to emerging languages 2012; satellite of strange loop, in St. Louis; anyone feels like getting involved; end of september
- Graydon: maybe better to discuss in a bug, but: we've talked a little about dynamic scope; dynamicalling scoped exception handling, variables, neither, both; particularly I've been thinking there are some experiments concerning region-based allocation, and it occurs to me dynamic stacks of arenas are not a bad candidate for dynamically-acquired variables; would be very pervasive; anyone have gut reactions?
- Marijn: one data point: our current approach to safe reference analysis would fall apart, but it's already shaky so maybe we should abandon that
- Patrick: several points: first, consensus is they're not a disaster; not opposed in principle; in terms of arenas, we'd have to think about the types to make sure that works; tricky when storing arenas in these things, b/c it imparts a hidden region polymorphism on the functions
- Niko: have to build it into the type
- Patrick: think it could work but have to be careful; other thing is that classes can impart a little bit of state without having to pass contexts around explicitly, so my instinct is we should try classes for a bit and see how it feels
- Niko: I think impls are even possibly a better fit for this than classes; can spread across multiple files
- Patrick: could use traits
- Niko: yeah
- Marijn: dynamically scoped thing can be seen through functions that don't cooperate in the passing, so it's more powerful; 4 years full-time clisp they were quite awesome
- Patrick: biggest motivation right now is trans, and I think we could experiment with classes
- Dave: invariant we have right now: no dependency on state; would lose that invariant
- Niko: could have a couple special arenas that serve this purpose; so we'd have some dynamic variables for special cases and still keep that property, though it would lose the general power
- Patrick: let's try to explore that
- Patrick: kind of like auto-release pools
- Niko: yeah
- Graydon: so, some interest there, not straight-up horror; not sure how well that dovetails with concept of at-error-site handling; unwinding is a diff issue, but maybe recover at error site potentially relates; this is all 0.3 / 0.4 stuff
- Niko: I've been considering whether we should have a monadic style, like a "result monad" b/c it's a pain to propagate errors
- Graydon: yeah, needs more design/exploration time
- Niko: I had something else but I forgot; I'll email when it comes back to me; not urgent
- Dave: packing bits and pointer types, special "pack" syntax?
- Patrick: maybe just a library with accessors
- Patrick: how much do we want to be interoperable with C?
- Niko: if we go crazy optimizing, it will be hard to predict layout
- Marijn: annotation is best approach: "just leave this in simple form"
- Dave: sort of like 'extern "C"'
- Graydon: pragma of some sort
- Jesse: another Moz problem we have is -1 is a special value, everything else should be unsigned; having sentinel values but not wanting an extra word
- Dave: seems like you could have another library for that
- Graydon: enums allow discriminant values; if you could say "this enum has to fit within this rep type"
- Dave: library that's equivalent to opt(int) but size-optimized?
- Graydon: that's probably the best way to approach it, a newtyped-int whose operations are hidden; you can check for the sentinel value
- Jesse: want alt
- Niko: could have a conversion to opt(int)
- Dave: need to make sure that generates code equivalent in perf to checking for -1
- Jesse: also may want more than one sentinel value
- Niko: might be nice to have a partial-function syntax, but that's another story altogether; basically an alt syntax that is a closure; I've wanted that many times
- Jesse: me too
- Dave: these sound like nice conveniences worth RFC's or bugs
- Patrick: do people mind if I experiment with making block contexts into an arena; trans function signatures will get unglier, will need fcx
- Niko: would rather they become impls to avoid this ugliness; but I don't mind experimenting; been wanting them to be impls anyway
- Marijn: not sure it'll feel much better; stuff becomes no less explicit than it currently is
- Niko: guess it's a matter of taste; to me it feels better, even if it's not really better
- Patrick: I think it will improve the performance though
- Niko: if you use an arena, you mean
- Patrick: biggest sources of traffic for malloc are block context, bit of hash map allocation, and also some really inefficient things resulting from copying vectors; should start moving fwd on fixed-length vectors, slices, etc for 0.3; stuff that makes them not unique and allows you to create them on the state; egregious example: io_writer::write_char allocates a big vector just to write and then frees it
- Graydon: agreed; should come up as soon as you feel confident regions are useful enough to build on
- Marijn: a great use case to try out how well they work; give it a shot with arenas for block contexts
- Graydon: cool, I'll keep pushing towards 0.2 release; try not to land destabilizing builds; exciting experiments go in branches for now
- Patrick: what about jemalloc?
- Graydon: how's that going?
- Brian: I have a branch with it; basically working, kinda lost enthusiasm for it since it barely dented graphs on the bot; noticeable improvement but not as noticeable as a lot of the swings happening lately; does create another configure script that has to be run
- Jesse: what were you measuring? big advantage in Firefox was fragmentation; after allocating and freeing a lot of things, not as much free space fragmentation
- Brian: wasn't doing anything like that, just our standard benchmark
- Graydon: windows malloc has tremendous perf problems; think you probably won't see a lot of the effect it has via perf scripts
- Niko: maybe we should have an intern work on performance benchmarks
- Graydon: that could be great
- Dave: great idea
- Brian: if I land jemalloc... I'll do OSX tests and Windows and see what happens
- Graydon: not opposed
- Brian: I'll try to come up with a fragmentation test
- Niko: probably have to do allocations in weird orders
- Patrick: could port v8 splay benchmark, think that's a good test of fragmentation; creates insane representation of a tree, adds and removes nodes in crazy orders
- Brian: if I do land jemalloc, is everyone ok with another configure script, or should I integrate jemalloc's configure script into ours? means another autoconf script
- Niko: another thing I have to do manually?
- Brian: all automated, just more scripts
- Graydon: it's not gonna run often; as long as rerunning is only predicated on changes to jemalloc; we don't reconfigure libuv often, for example
- Niko: but we do run configure a lot now
- Graydon: I made it oversensitive somehow
- Niko: for me it runs every make
- Jesse: can LLVM make optimizations all the way through jemalloc?
- Niko: what does that mean?
- Jesse: if jemalloc has function with early return, a particular Rust caller's never gonna hit that early return, can jemalloc be inlined?
- Niko: no
- Patrick: if you put it in intrinsics and statically linked... since malloc is so incredibly dynamic, I have a hard time imagining LLVM gaining much from inlining any part of it
- Brian: no
- Niko: not only that, but we'd have to inline the source, b/c LLVM doesn't pull things from assembly
- Patrick: that's not that hard, but I just don't think it'll matter
- Jesse: if you have a fixed-size allocation, you don't need the function with all the branches
- Niko: yeah, but all that is is where it looks up the bucket index; that's a small part of the function