On Tue, Jul 28, 2009 at 7:06 PM, Subramanya Sastry<sss.li...@gmail.com> wrote:
> I probably lean towards the latter. But, insofaras all implementations have
> bugs and specs are incomplete, you have some leeway probably. In addition,
> I am not sure if there is a solid language spec for Ruby which also leaves
> the playing field a bit hazy.
>
> In that sense, the spec is what is implemented and in the case of Ruby, it
> might be whatever is verifiable through RubySpec tests if that is what all
> language implementations settle as the de facto standard. So you might be
> right in saying that this is JRuby, and not Ruby, and this might be a
> political negotiation between various implementations.
>
> In any case, if (a) expectations of what is unsupported are clear upfront,
> and (b) violations of assumptions are detected and flagged in some obvious
> fashion rather than failing silently or mysteriously, that might still be
> acceptable behavior.
It's also possible that when faced with the potential for a
significantly faster Ruby implementation, people will be willing to
opt out of certain features like using a block as a binding. If we
offered such options and made those optimizations *hard*
optimizations, everyone would be satisfied. If applications or
frameworks did not run with those settings on, it may put pressure on
Ruby folks at large to avoid using fundamentally unoptimizable
features and find other ways to accomplish what they want to
accomplish.
It's certainly political though.
> This is true if the problem is at the level of source-code / algorithmic
> implementation of the core classes. But, if the problem is because of how
> the core classes perform because of the language implementaiton, this is not
> true. For example, the opts you implement for the language might lead to
> good performance for the core classes too. Obviously, I am speaking
> hypothetically since I don't know much about what the performance
> bottlenecks are in the core classes.
Yes, that's certainly true. And if we have better mechanisms for
implementing the language, we'll have a better idea how the core
classes can be optimized. For example, we currently don't have any way
to do inline-cached calls from Java code, because there's no good
place to store the cache. That means that almost all dynamic calls
made from Java code are slow path every time, hitting the per-class
hash of cached methods. Who knows what untold amounts of performance
we lose because of things like that peppered all over the codebase.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
