<br><br><div class="gmail_quote">On Thu, Feb 12, 2009 at 11:55 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Again Im not trying to be offensive or toot my own horn. I'm just trying to be objective.</div><div><br></div><div>Regards,</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div><br>