From: John Carter Date: 2006-05-23T10:18:10+09:00 Subject: How to Improve Performance Now. Re: Zed and Luis drop the bomb onRuby's poor performance --Boundary_(ID_yQ0gfPfEqep2TUKA3kgatQ) Content-type: TEXT/PLAIN; format=flowed; charset=X-UNKNOWN Content-transfer-encoding: QUOTED-PRINTABLE On Mon, 22 May 2006, cremes.devlist@mac.com wrote: >> I=92ll be honest right away though and say that Ruby is slow. The = Ruby=20 >> community has been ignoring the huge =93performance=94 elephant st= anding in the=20 >> room and they need to start talking about it so it goes away. Elep= hants=20 >> hate being talked about. There are a few efforts to make Ruby fast= er, but I=20 >> see a lot less action than is needed to solve the problem. Hokay some concrete suggestions on speeding up the here and now.... A Good Thing would be to have a Performance test suite. You can't optimize unless you have a realistic measure of performance. That would be a Good Thing for someone to create. Ruby is based on gcc, gcc has grown some nifty ways of speeding thing= s up. Much of ruby was written _before_ gcc grew these features but it is really worth considering now. Simple way number one. Currently Ruby is compiled -O2 usually for generic i386 Obvious answers - Compile -O3, gcc, especially since version 4.0 has grown some rea= lly nifty optimizations. Almost the whole point of version gcc 4 - Compile -march=3Dpentium4, or -march=3Dk7 or whatever the machine= it's actually running on is. This gives you... - Tuned for the pipeline of that CPU. - Uses the new fancy instructions for that CPU. - gcc has / is growing profile based branch prediction. This is som= ething ideal for an interpreted language with a largish test suite! Not quite so easy answers... Use gprof to get some profile data. * Use inline functions. C++ and STL have forced all compilers today t= o be very very Good with inline functions. In several respects inlin= es are better than macros. * const and pure attributes can speed things up too. Ruby is _not_ gcc warning clean. Some gcc warnings are actually perfo= rmance related. Especially those to do with... * Alignment. * Strict aliasing. * Pointer casts. A community "lets all clean up get Ruby -Wall -W clean" would be A Go= od Thing. The register / cache / memory hierarchy speed differences are becomin= g really really huge in modern machines. Some thought as to keeping things "in cache" especially in things wit= h tight inner loops like Ruby can make a Big difference. Thus a Good Thing to try would be to feed Ruby to cachegrind (a tool = in the valgrind.org suite) John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.n= z New Zealand Carter's Clarification of Murphy's Law. "Things only ever go right so that they may go more spectacularly wro= ng later." =46rom this principle, all of life and physics may be deduced. --Boundary_(ID_yQ0gfPfEqep2TUKA3kgatQ)--