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 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
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 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 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
> 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 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
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
[rust-dev] criteria for core lib
Hi, I'm in the process of adding a 'core' lib that will complement std in the following fashion: - core will be automatically 'use'd in any crate, unless you ask for --no-core when running the compiler. - everything in core will be automatically imported into the crate you're building, again, unless you pass --no-core The idea here is that some "library" code is so universal as to be not worth burdening every user with writing "use std;" and -lstd with every time they build a program, and that as libstd grows, the tension to "not have to link or distribute libstd" for small/simple programs grows stronger. Nobody wants a static-linked "hello world" to be 10mb. The interesting question is: what are the criteria for something to be in 'core' vs. 'std'? I've been thinking of the following criteria: - If it's a module that relates 1:1 with a built-in tycon, it goes in core. This means u8, u32, ..., str, vec, all go in core. - If it's a module that relates 1:1 with a built-in runtime service, it also goes in core. This means task, comm, os, fs, sys, dbg, rand, unsafe, test, time, uv, run_program all go in core. - If it's a module that covers a type we wind up using "in nearly every nontrivial program", it goes in core. This means option, either, result and extfmt go in core. This is quite a bit of the stdlib, but not all. It leaves: bitv, cmath, ctypes, c_vec, deque, ebml, four, fun_treemap, getopts, json, list, map, net, rope, sha1, smallintmap, sort, tempfile, term, treemap, tri, ufind, unicode, util all in std. And as we add more stdlib stuff over time (I think I'd prefer a big libstd -- see https://github.com/graydon/rust/wiki/Standard-library-notes) we will be making std larger, and core not-much-larger, possibly even smaller as we reimplement rt stuff in rust code. 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?) -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
