On Fri, Jul 18, 2014 at 04:01:45PM -0300, Casimiro de Almeida Barreto wrote:
> 
> On 16-07-2014 00:27, David T. Lewis wrote:
> >
> (using trunk updated 64bit image and 4.10.2-2614_64bit SqueakVM)
> > I tend to switch back and forth between a variety of VMs and images (Spur, Cog,
> > interpreter VM etc). Lately I have been doing my updates from a format 68002
> > 64-bit image. Just curious, is anybody else out there using a 64-bit image on
> > a regular basis and keeping it updated from the trunk development stream?
> >
> 
> It works but:
> 
> a) Seems to be slow (although I'm used to the cogvm which is faster than
> SqueakVM)

It is definitely slower than Cog. I recall from a few years ago (using whatever
PC I had at the time) that the 64-bit image ran slower than the 32-bit image.
However, on the PC that I am using now, the 64-bit image is somewhat faster than
the 32-bit image. I cannot explain the difference. I expect the 64-bit image
to be slower due to various inefficiencies in the use of sqInt as a default
data type throughout the VM (which is a 64 bit integer when the VM is compiled
for the 64-bit image). Maybe some CPUs handle this difference more efficiently
than others, I really don't know.


> b) Somethings just itch my ears like:
> b.1) Compiler recompileAll fails (and shouldn't)
> b.2) Smalltalk condenseChanges that works for 32bit images work, fails
> in 64bit image.

Running the full unit test suite will also lead to some unpleasantness.

> 
> b.2 is not that important but b.1 shows that there is code that cannot
> be re-compiled and it's not a good sign.
> 

That is not good, and it might be worthwhile to find the cause.

Dave