Re: [rust-dev] criteria for core lib
Virtual methods all over Gecko (Raptor, originally) really hurt. QI, AddRef/Release (nonsensical for arena-allocated objects, but the COM disease was rampant), all the core rendering object methods were virtual. De-virtualization took years. KHTML (now WebKit) avoided this costly mistake. It's not the same as what's discussed here but I wanted to support the concern about indirect call overhead. It's not a premature optimization to consider at this juncture. /be On Dec 4, 2011, at 10:00 PM, Patrick Walton wrote: On 12/04/2011 09:39 PM, Patrick Walton wrote: Strongly disagree. If we cannot inline stuff like map, we cannot create a performant browser engine. There is no way around this. I should elaborate: Short of just telling users they can't use the looping abstractions in the standard library if they want performant loops, which seems like a non-starter to me. I suspect that would just lead to systems programmers writing loops by hand, using macros, using the C preprocessor, or something like that. All of those options would result in relatively unstructured workarounds that miss out on the benefits of the functional abstractions we're offering. We already see high-profile projects like SQLite do so-called unity builds where they concatenate everything into one enormous .c file. This is in spite of the fact that C already has macros and static/inline functions. We could do measurements here with instrumenting rustc, but I'm not sure it would be relevant. What would be more relevant would be something like inserting two function calls (one direct, one indirect) around every pixel in pixman's alpha blending routines and seeing what the performance of Firefox becomes. But I think we already know what the results of this test would be. Sorry for wording this so strongly, but I feel that this is an important issue. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
On 03/12/2011 3:41 PM, Brian Anderson wrote: With regard to the large vs. small std question, I'm beginning to agree with marijn (and I think patrick) that it would be better to have many small crates, and make rustc/cargo powerful enough to locate them automatically and add them to the compilation with little effort (primarily because of mobile considerations). I do think we want to provide these as 'standard' libraries, just not a single stdlib. Plausible. Keep in mind there are limitations: - A cross-crate call cannot inline. - A cross-crate call isn't even just direct! It's indirect through a PLT table on linux or import-table on windows. - A cross-crate definition can't be recursive. In general, my experience has been that projects that start with the lots of little DLLs approach tend towards one big DLL over time. Actually, now that I stare at it, the no-inlining issue might make the core/std split a pretty bad idea at this point. Maybe sometime in the future if we get crate-to-crate inline exports done. -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
Actually, now that I stare at it, the no-inlining issue might make the core/std split a pretty bad idea at this point. When platform limitations stand in the way of proper software design, I think we should be working on circumventing them. Telling people to write monolithic libraries because the linker model penalizes a more modular approach seems very unfortunate. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
On 04/12/2011 1:19 PM, Marijn Haverbeke wrote: Actually, now that I stare at it, the no-inlining issue might make the core/std split a pretty bad idea at this point. When platform limitations stand in the way of proper software design, I think we should be working on circumventing them. Telling people to write monolithic libraries because the linker model penalizes a more modular approach seems very unfortunate. I agree it may be worth solving the cross-crate inlining thing eventually. The key phrase in what I wrote is at this point. We don't have it solved *now*, so right now I might wind up mothballing the core/std split patch, for now, if it turns out to be very costly. I'll do some measurements to see. It not cost much at all. Modern CPUs predict indirect branches pretty well and inlining isn't always a win, due to cache pressure. We're already PLT-jumping into out-of-line librt code pretty frequently. I don't agree with the latter statement you make here, as a universal guideline. Perfect is the enemy of good. Sometimes we make sacrifices to the gods of platform limitations. Monolithic libraries are common in the C-linkage-model world, and it's not always for easy-to-circumvent reasons. There's a set of hard engineering tradeoffs within compilation models, linkage models, memory models, etc. I'm more interested in finding a reasonable balance. Cross-crate inlining (when and if we do it) is a mixed blessing anyways. It hurts data and procedural abstraction -- both virtues of proper software design -- in order to help compile-time (but not run-time) modularity. I'm happy to experiment with it, but I don't think it should be seen as a panacea either. The tradeoffs are numerous. -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
On 04/12/2011 2:02 PM, Graydon Hoare wrote: core/std split patch, for now, if it turns out to be very costly. I'll do some measurements to see. It not cost much at all. Modern CPUs -- ... it ^might not cost much at all ... -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
On 12/04/2011 02:02 PM, Graydon Hoare wrote: Cross-crate inlining (when and if we do it) is a mixed blessing anyways. It hurts data and procedural abstraction -- both virtues of proper software design -- in order to help compile-time (but not run-time) modularity. I'm happy to experiment with it, but I don't think it should be seen as a panacea either. The tradeoffs are numerous. Strongly disagree. If we cannot inline stuff like map, we cannot create a performant browser engine. There is no way around this. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
On 12/02/2011 10:48 AM, Graydon Hoare wrote: Are these agreeable criteria? Do you want fewer or more modules in core? (Alternatively: Do you think this is a terrible idea? Do you want to restart the conversation about large-vs-small libstd?) I agree with your criteria. With regard to the large vs. small std question, I'm beginning to agree with marijn (and I think patrick) that it would be better to have many small crates, and make rustc/cargo powerful enough to locate them automatically and add them to the compilation with little effort (primarily because of mobile considerations). I do think we want to provide these as 'standard' libraries, just not a single stdlib. -Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
I agree with your categorization of what should be in core. I'd split the stdlib into different crates though -- most programs don't need json/rope/treemap/etc . We could put them in a standard distribution, as separate crates, or when the package manager is functional, simply rely on that for providing them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
