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@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel