On 9/15/06, Kenosis <kenosis / gmail.com> 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