From: pat eyler Date: 2006-09-16T02:51:23+09:00 Subject: Re: Benchmark for Ruby On 9/15/06, Kenosis wrote: > > Hugh Sasse wrote: > > On Sat, 16 Sep 2006, M. Edward (Ed) Borasky wrote: > > > > > Hugh Sasse wrote: > > > > > > > I've tried, but FORTH still hasn't clicked with me yet... > > > > > > > > [...] > > > > > > > Thanks, I'll reply off list about that. > > > > > > > There exists at least this effort to use Genetic Algorithms for > > > > tuning compiler options. I've not explored it yet. > > > > > > > > http://www.coyotegulch.com/products/acovea/index.html > > > > > > > > One may need a cluster of machines (of many platforms?) to do this > > > > usefully, but still. Maybe Rinda can help us all contribute... > > > > > > I think I installed acovea once -- it's part of Gentoo -- but I don't > > > remember doing anything with it. But the concept is certainly > > > intriguing, and might be more so to the folks on this list who are > > > always talking about how machine cycles are cheaper than programmer > > > cycles. Of course, if the programmer has to spend his or her cycles > > > waiting for a genetic algorithm to converge ... > > > > > > :) > > > > GA's aren't that quick, and would not be for a ruby build. But it's > > something to explore, just because it might teach us something. > > > > > > I've had bad experiences in the past with this sort of optimization. > > > "Real" compiler optimization is a hard problem in the complexity sense, > > > plus there's all the time you have to spend correctness-testing the > > > > Well, at least we have a set of tests for ruby, and we can use that > > as part of the fitness function. > > > > > optimized versions. My experience has been it's far better to pluck the > > > low-hanging fruit, which is what gcc does by itself, and which is what > > > the designers of virtual machines do. > > > > People have stated that implementation method despatch in ruby are naive. > > > > http://smallthought.com/avi/?p=16 > > > > that creating Procs, and continuations are slow: > > > > http://lambda-the-ultimate.org/node/1470 > > > > and other people have mentioned the garbage collection system. > > > > I'm certainly not in a position to suggest what might be done about > > these things, or to denigrate the implementations as they stand, but > > these are about the only specific things I can find people pointing > > to, (other than the general remarks about ruby being slow, which add > > more heat than light). So I think we have some juicy pieces of fruit > > to bite into here, but I don't think they are low hanging, not for > > me anyway. :-) > > > > Hugh > > I can't recall whether I read about this on this site or in some > magazine article but I recall it being interesting to me: I think it > was called profile driven optimization. My vague recollection is that > gcc can optimize based on a runtime profile. So, you run ruby over > your application while profiling it all together, essentually profiling > ruby in the context of your application. Then you use the profile guide > gcc to rebuild a version of ruby optimized for your application. Might > be worth some research. RedHat Magazine had an article on GCC optimizations that talked about this: http://www.redhat.com/magazine/011sep05/features/gcc/ it's also a recurring topic at the GCC summit: http://www.gccsummit.org/2005/view_abstract.php?content_key=7 http://www.gccsummit.org/2006/view_abstract.php?content_key=17 > > Ken > > > -- thanks, -pate ------------------------- http://on-ruby.blogspot.com