[Vm-dev] 64bit FFI?

[Eliot Miranda]

On Thu, Feb 12, 2009 at 11:55 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> Eliot Miranda wrote:
>
>> Let me further suggest that 2) is pointless, in that it can't scale beyond
>> the 32-bit address space but uses about 1.5 times the space of a 32-bit
>> image as it tries to do so.  i.e. it'll fail a lot earlier than a 32-bit
>> image.  Further, if a 64-bit image is larger than will fit in a 32-bit
>> address space one *cant* run it on 2 because it won't fit.
>>
>
> It is not pointless at all. If we were to switch our servers to 64 bit
> images while allowing customers to deploy on 32bit, we'd be nuts trying to
> manage both 32 and 64 bit versions of the same image and trying to keep them
> in sync. Much easier to give them a 32bit VM that can run the very same 64
> bit image that we use everywhere.


I respectfully disagree.  The VisualWorks 32-bit to 64-bit converter
produces something one can deploy immediately.  So its not difficult to keep
the two in sync.  One merely passes the 32-bit image through the converter
and fires up the 64-bit image.  Saving the 64-bit image can save you a bit
of start-up time, so is worth-while doing.  Both these processes can be
wrapped up in a shell script and run without user intervention.  So to keep
the 64-bit image in sync with a 32-bit one is easy.  So 2) still strikes me
as pointless.

In addition, it is this very combination that allows people without 64bit
> boxes to actually help in working out the quirks with the 64bit images. I
> don't think we would have gotten where we are without it.


I don't want to be sarcastic, but that doesn't seem to be very far.  From
Bert I get the sense that no-one is actually using 64-bit Squeak images (he
just said as much).  The Squeak 64-bit image format is not particularly
ambitious.  It doesn't give one wider SmallInteger range, more identity hash
bits, larger objects, more literals in a method or faster floats, or
immediate characters.  It is as naive a conversion to 64-bits as one can
imagine.  I don't see that the rather conservative approach taken with the
64-bit VM has produced something particularly compelling.  Note that a
memory-bound 64-bit Smalltalk application that can't take advantage of
64-bits to speed-up computation (as for example immediate doubles do) simply
uses twice the memory bandwidth to accomplish exactly the same thing as a
32-bit application, and so if memory-limited (doesn't fit in cache) can run
twice as slow.  The only advantage such a 64-bit system has is in being ale
to instantiate more objects.

VisualWorks' 64-bit implementation on the other hand provides immediate
doubles that have performance only 1/2 that of SmallIntegers, provides
61-bit SmallIntegers and 20-bit id hashes vs 14 bits, much faster at: and
at:put:, and is being used by customers using images > 4Gb in production.  I
think its got a lot further, and it didn't waste effort with 2) in doing so.
 So that's an existence proof that 2) doesn't help.

Again Im not trying to be offensive or toot my own horn.  I'm just trying to
be objective.

Regards,
Eliot

>
>
> Cheers,
>  - Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090212/05549f79/attachment.htm