From: John Carter Date: 2006-05-30T13:57:39+09:00 Subject: Re: How to Improve Performance Now. Re: Zed and Luis drop the bombonRuby's poor performance On Thu, 25 May 2006, Juergen Strobel wrote: > There are big problems with this approach. None of gcc's optimizations > beyond -O2 come for free. They usually enlarge the binary, make > debugging really hard, impact thread-safeness or even correct > functionality (omit frame pointer). You already have instruction reordering and register only variables at -O2. ie. Debugging is already hard. You can switch off -fomit-frame-pointer Vomit frame pointer doesn't break correct C functionality, just makes debugging harder. One of the nice things about Rubies non-native thread implementation is... it's not multithreaded from the C code point of view! Certainly some of the optimizations can make the binaries larger, on a desk top who cares? Some optimizations may make ruby slower, that is why I said, explicitly upfront item number 1, we need a standard benchmark suite of "typical" ruby applications so we can know whether we are improving things or not. > Reworking ruby for better alignment of memory accesses might be > useful. After determining how much of a problem it is though. Yip, last time I look at the i*86 CPU instruction cycle counts, the penalty for misaligned references was significant. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand Carter's Clarification of Murphy's Law. "Things only ever go right so that they may go more spectacularly wrong later." From this principle, all of life and physics may be deduced.