On 5/16/11 12:21 AM, Graydon Hoare wrote:
Two? It should only be one. Range calls block, block runs, range does += 1, range calls block again. It's also not exactly a surprising indirect function; it keeps calling the same one, from the same place in the code + stack. IOW it'll *probably* be well predicted.
That's true, sorry.
It is definitely going to inhibit some optimizations, it's a question of asking which ones and how high the costs are. Measure?
Well, I'm not sure what kind of measurements we can usefully do to demonstrate this. I could certainly write a loop microbenchmark, but that won't tell us much. This doesn't hurt us much in rustc because (a) rustc is mostly tree-traversal, not hot inner loops; (b) we're using while loops in rustc anyway. I suspect this will be the kind of problem we will see in things like video decoders... but that's a ways off :)
I think you mean more than "static linking", since LLVM is not a linker; you mean static linking where the .a file actually contains LLVM bitcode, a la the LLVM-LTO approach. That's plausible. It's *different again* from actual static linking. And it's different from pickled ASTs, and different from macros. So there are like ... 4 points on the spectrum here in addition to our existing compilation strategy:
Yes, I should have been more clear when I referred to static linking. I think traditional static linking is mostly obsolete with the advent of LLVM bitcode; the only reason one would want it is if the object files aren't in LLVM bitcode format (not a problem we have in this case), or for compilation speed (which is a fair point).
- We want a macro system anyways. So let's build that soon.
Agreed :)
- You only have an inlining problem *when* you're dealing with separate crates. Granted, uint::range is "standard library fodder", but if you have some custom data structure X with iters on X implemented in the same crate as the iter-callers, LLVM may well inline the iter already. And uint::range is one of those cases that will fall into "supported by a scalar-range special case loop", so let's not over-generalize the problem too quickly.
Right, that's one of the approaches that I was considering (but left out for the sake of email brevity). The issue is that I suspect a fair number of folks will end up writing Rust in a functional style and use functions like map, filter, and possibly reduce/fold liberally. I worry about them getting burned. We could of course add language support for those constructs too a la Python's list comprehensions, but that increases the complexity budget.
The reason is simply this: if "standard wisdom" is to use LLVM-LTO against the standard library to get "adequate performance", you get two big follow-on problems:
Sorry, I should have been more clear. What I'm proposing is to segment the standard library into two parts: a small, performance-critical part that benefits from LTO and a larger, dynamically-linked part. This is what I was getting at by defending dynamic linking; there are parts of the standard library that we would definitely like to be able to share among processes, to be able to patch for security issues, and to avoid recompiling. But there would be a small core that would be shipped as a .bc file and linked at LLVM optimization time into Rust binaries. This allows us to alter the dividing line between static and dynamic over time.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
