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
