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
[rust-dev] LLVM upgraded to svn 145779
For most people this should require little action. The first time you run make it will reconfigure, then the build will likely fail. Run make again and it should work. If things still don't work, then wipe the build directory and start from scratch and let me know what happened. This pulls in commits 145765 145766, which are required for split stacks. We are no longer compatible with LLVM 3.0. -Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] do we need lambda?
Hello,
I wanted to do a quick straw poll to ask whether we still need a lambda
expression, given that we have blocks and named functions? Searching
the rust code base, I found that *every* use of lambda was of the form:
|let foo = lambda(...) {...}| which would (in my opinion) be better
written: |fn foo(...) {...}|.
I am not asking because I like stripping out unused expression forms,
though I do, but rather because I am thinking about the precise design
for unique closures (separate e-mail coming soon) and the fewer ways to
declare closures the simpler the job becomes.
Niko
___
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
