On 16/05/2011, at 5:21 PM, Graydon Hoare wrote: > > Yeah. I'm not really a "fan" of dynamic linking. There are also studies > showing the putative memory savings of dynamic linking are .. pretty > hypothetical. But then it really depends on the system load, system design, > what you're measuring, and and who you ask.
Its not about memory savings. Its about delayed binding. This is especially important for long running service programs where you can add new features or even new versions of modules to the program without stopping it. > I mostly wanted dynamic linking so that people who *are* convinced they want > it can have it, for whatever reason. It's a common sentiment and as I said > before, I'm a pluralist. I'm usually fine statically linking the programs I > write. But I want dynamic to work. In Windows a lot of libraries are ONLY available as DLLs. > > - Pickling ASTs so that we can load in STL-like "declared externally > but mixed in to your compilation unit" functions. So that the > inlining or intertwingling can happen at the front-and-middle ends, > not just the LLVM layer. Felix does this. It save enormous amounts of parsing time. > > - Powerful macros that cover the "needs to be efficient" cases as well > as the various other macro scenarios. Definitely front-end! I do not understand the need for macros. Could someone explain? If you have polymorphic functions you basically don't need macros. But perhaps I misunderstand what a macro is in Rust. > > - We want a macro system anyways. So let's build that soon. Why? Felix had macros at many levels, very powerful. I threw them out. The languages is better without them. Conditional compilation is supported by ordinary control flow and compile time constants (the compiler optimises away unused branches even before types are determined). > > I'd probably say go with the macros and the scalar-range loop *first* while > measuring the cost of DLL vs. crate-internal iter vs. scalar-range loops. If > you have a serious performance problem that definitely can't be solved with > scalar-range optimizations, then start digging into the LLVM-LTO stuff. Just in general: the cost of function calls is enormous. The cost is not just in the call, it is not just in the parameter passing. The cost is that when you inline the function, the resulting substitutions lead to code that can be further optimised because everything just got more specific. -- john skaller [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
