I think because of my work fiddling on gcc parms/registers or not for macintel that Ian had incorporated those changes into the unix vm build last dec which affects the compare of current/previous VMs, although I've not checked to see if that applies to outside of the darwin build logic.
For the bytecode and send/sec the difference is quite large. However which gcc version you use plus options plus hardware can make quite a difference. The clue to the better rates is if the assembler to support the first couple of byte codes in the interpret() loop looks like below. Poorer optimizations can have 12 or more instructions, verus the more optimum 9.
.globl _interpret _interpret:
after the jump tables .long LXXXXX
you should see something like:
L10161: addl $1, %esi movzbl (%esi), %ebx addl $4, %edi movl _foo, %eax movl 84(%eax), %eax movl 4(%eax), %eax movl %eax, (%edi) movl 512(%esp,%ebx,4), %eax L10421: jmp *%eax
On Jan 15, 2007, at 2:37 AM, goran@krampe.se wrote:
Hi Ian and all!
"Philippe Marschall" philippe.marschall@gmail.com wrote:
2007/1/15, goran@krampe.se goran@krampe.se:
My guess is that the combo you compiled (3.9-9, 4.0.3) that turned slow somehow failed to get gnuified. Just a wild guess.
Wasn't me. It's the stock from squeakvm.org
Ah... Ian, could you perhaps check the performance of the binary 3.9-9 VM on squeakvm.org? As per this posting:
http://lists.squeakfoundation.org/pipermail/vm-dev/2007-January/ 000977. html
I presume this is the intel binary we are talking about. Did something go wrong with gnuify or so?
I don't have a box handy to look into this right now.
regards, Göran
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===