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.