Re: Benchmark for Ruby
- From: "pat eyler" <pat.eyler@xxxxxxxxx>
- Date: Sat, 16 Sep 2006 02:51:23 +0900
On 9/15/06, Kenosis <kenosis@xxxxxxxxx> wrote:
Hugh Sasse wrote:
> On Sat, 16 Sep 2006, M. Edward (Ed) Borasky wrote:
>
> > Hugh Sasse wrote:
> >
> > > <OT>I've tried, but FORTH still hasn't clicked with me yet...</OT>
> >
> > <not-quite-OT>
> [...]
> > </not-quite-OT>
>
> 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
.
- References:
- Re: Benchmark for Ruby
- From: M. Edward (Ed) Borasky
- Re: Benchmark for Ruby
- From: Hugh Sasse
- Re: Benchmark for Ruby
- From: M. Edward (Ed) Borasky
- Re: Benchmark for Ruby
- From: Hugh Sasse
- Re: Benchmark for Ruby
- From: Kenosis
- Re: Benchmark for Ruby
- Prev by Date: Re: not sure what is wrong. strange error
- Next by Date: Re: Need help about Ruby with text file
- Previous by thread: Re: Benchmark for Ruby
- Next by thread: Re: Benchmark for Ruby
- Index(es):
Relevant Pages
|
