On 16/05/2011, at 7:37 AM, Patrick Walton wrote: > > I'm pretty sure that LLVM can inline away the overhead of range(), by first > inlining the iterator itself, then inlining the for-each body. But, in order > to do that, it needs to statically know the iterator definition. So range() > can't be dynamically linked anymore. The simplest solution I can think of is > to allow both static and dynamic library crates.
My view as expressed in some messages already is that you can have both opaque function calls AND text for inlining. When you're "rapid prototyping" you just use the slow calls to avoid the compilation costs of doing large scale analysis. When you're doing a release, you compile a lot more text and do more inlining, and don't call the prebuilt functions so often. This isn't so much "static and dynamic" because I do not believe you can leave optimisations like inlining to LLVM. No matter how good LLVM is at doing this it cannot compete with a compiler that understands the high level semantics of the users code. The way I picture this is you have a tree of library "things" ending up with leaves which are individual functions. To compile fast and run slow you compile all the functions separately. Change the program, recompile the changed functions (only). To get better performance you just expand the "compilation unit" by moving up the tree. Now you compile sets of functions so that calls within these sets are inlined and optimised, but call across from one set to another aren't. In the extreme case you can move the trade-off slider all the way to "whole program" and that get rid of ALL ABI overheads (other than calls to non-Rust functions). Whole program analysis can achieve blinding speed but comes at a heavy price. Felix can ONLY do whole program analysis, although it uses caching to reduce the cost. This is the WRONG WAY (TM). Rusts approach is correct: get the external interfacing working first. Then if you can make the definition of what's external flexible you can open up the possibility of heaving inlining at any level of granularity. IMHO it is not necessary to do heavy optimisations early in the development of the language: you can always add that later. It is important to get the "flexible granularity" of compilation unit going early though (if you choose to do this kind of thing). -- john skaller [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
