[MacRuby-devel] branches/experimental

[Matt Aimonetti]

Hi Charlie,

 I don't think/hope you do it on purpose, but it seems that you're asking
questions just to prove that Laurent is wrong and that whatever he will do
will end up slowing down the current experimental branch.

I understand that you are upset about Antonio Cangiano's blog post with
early benchmarks, but I have a hard time telling if you are trying to help
or trying to hurt the project. From my view point, it seems like you are
disseminating negative information(speculations) designed to undermine the
credibility of MacRuby.

Let's just wait and see.

Regards,

- Matt

On Sun, Mar 29, 2009 at 12:09 PM, Charles Oliver Nutter <
charles.nutter at sun.com> wrote:

> Laurent Sansonetti wrote:
>
>> I don't think it's a good idea to provide a way to turn off optimizations
>> and I do not see the point in benchmarking dead code in general (I would
>> never do this).
>>
>
> I think it's actually very useful to provide a way to turn off specific
> optimizations, if only because they may eventually run into cases where they
> break something. But they're also useful when writing benchmarks that have
> dead code on purpose...
>
> For some benchmarks it's very difficult to get a reasonable measurement
> without forcing some dead code to run. For example, benchmarking a single
> local variable access gets completely lost in the method or block invocation
> that surrounds it. By forcing several successive local variable accesses to
> execute, you get a better picture of what the actual cost is.
>
> At any rate, if you have good benchmarks for things like local variables,
> we can certainly use those for now.
>
>  Good to know, I just hope they are not doing this 30 million times in a
>> loop or something :-)
>>
>
> Well, it gets called numerous times per request.
>
> In the end, though, Rails performance has not actually been very
> execution-bound. We've had Ruby code running faster than Ruby 1.8 for almost
> two years, but we only recently started to post 10-20% performance gains for
> Rails itself. Rails performance, and probably most large applications'
> performance, all seem heavily dependent on core classes being as blazing
> fast as possible. It's a balancing act, and we often completely ignore
> execution performance for a whole release to work on core classes instead.
>
>  Yes, Binding is not implemented yet. Do not worry I have read the MRI
>> source code and know how Binding works and how to provide a compliant
>> implementation. Please stay tuned.
>>
>
> Well, I'd certainly like to hear what you're planning for this particular
> case. Just let me know when you're ready to talk about it. I've gone over
> several options when optimizing JRuby, and the block-as-binding issue makes
> most of them infeasible.
>
> - Charlie
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20090329/9d3956e5/attachment-0001.html>