Nicolas Cellier wrote:
2009/11/17 Eliot Miranda eliot.miranda@gmail.com:
Travis, Martin, what's the current demand like?
Having more than 4G of object memory is only one reason someone might want a 64-bit VM. Maybe you use integers > 2**29 but < 2**60 and would like them to be SmallIntegers for speed and/or space. Maybe you use floats and would like them to be immediate for speed and/or space. Maybe you want to call a function in a 64-bit shared library. Maybe you just want to run a pure 64-bit Linux system without all of those 32-bit libraries, which is becoming more practical as most common open-source packages are now 64-bit clean. (These days I have very few 32-bit executables on my systems.)
But yes, various size considerations were the driver for GemStone to go 64-bit. In GemStone, you don't have to have all of your objects in memory at the same time, so you could have more than 4GB of objects even on 32-bit. We had customers with more than 100GB of objects. But when you have that many object there were two problems:
1. In a 32-bit address space you can only cache <4GB of objects in memory. When you have 100GB of objects, the working set of frequently-accessed objects is probably >4GB, so things slow down with frequent disk accesses to swap objects in (and out, if modified).
2. The total number of persistent objects was limited to 2G objects due to use of a 32-bit object identifier, and some customers were approaching that limit.
Going to 64-bit fixes both of these; you can now have 2**40 objects, and use as much RAM as you've got for caching objects.
So GemStone VMs are now 64-bit. You can use a 32-bit VW VM as a client to 64-bit GemStone, by connecting client to server via a socket. But some of our customers put the client and server on the same machine and have the client VM load the server VM as a shared library, thereby getting rid of network stack overhead. You can't do that unless client and server are both the same architecture. So if you have a 64-bit server VM you have to also have a 64-bit client VM. This is an advantage to using 64-bit VW even if the client image is quite small, and this is indeed the major driver we've had in supporting 64-bit VW.
Nan trick or SmallDouble like trick or ?
For immediate floats: SmallDouble, definitely! At least that's what I'd like to see. :-)
SmallDoubles are currently bit-compatible between GemStone and VW, and I'm encouraging all dialects that go 64-bit and want immediate floats to adopt the same format. The only reason to do otherwise is if someone comes up with an immediate float format that is significantly better, and in the past few years of working with the current format it looks like the design choices were good ones.
Regards,
-Martin