So you sit there smug about the fact you built a 64bit VM, likely for hosting on your 64bit Linux OS.
{Or the unix one for Darwin, or that new fangled cocoa one}
However it's possible that it's running 1/3 the performance of the 32bit VM.
Did you check? Thought not...
So let's talk.
Are you using the gnuifed version of interp.c? If you don't know, well go check.
Are you using GCC 4.1 or higher?
The interpreter loop is highly tuned monster that suffers from compiler optimization issues. With
careful tuning parms as found in the macintosh xcode build project for the carbon VM using gcc 4.0
you'll get the most optimum performance.
GCC 4.2+ ?
Michael Rueger and I spent a few days attempting to get good performance out of GCC 4.2
WITHOUT success. I think that can account for at least a 33% slowdown.
So where does the other 33% slowdown come from?
Well when we compile the VM in 64bit to use a 32bit image each reference to an oops requires us
to add a 64bit memory start address to the 32bit oops number to resolve to a 64bit memory address.
Unfortunately GCC 4.2 growls, and produces the lousiest code possible to do this.
Maybe higher versions of GCC are better? Anyone care to test?
So some solutions.
(a) Ensure the squeak oops memory block loads within the 0-4GB address space.
See pagezero size for Darwin. Then alter the logic a bit so that sqMemoryBase is zero
and that the squeak memory accessors don't do the add of sqMemoryBase=0 to the oops address.
Although you might have to use GCC 4.2 you'll run 100% faster.
(b) Use the (non-free) Intel compiler
--
===========================================================================
John M. McIntosh <
[hidden email]> Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd.
http://www.smalltalkconsulting.com===========================================================================
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
