Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
It seems there are two support levels for Smalltalk in 64-bit scenarios:
Isn’t clear to me if a Smalltalk with a 64-bit image runs significantly slower than a 32-bit one. Please comment on your experience if you like. Is there any Smalltalk implementation which supports both (64bit VM + Image) or just 64bit VM?
There is and old 64 bit image and vm for squeak. At Esug I’ve pushed to get 64 bit support for Pharo going, but that’s moving forward slowly. [edit] And I see there is now an experimental 64-bit squeak vm and image for linux x86. [/edit] The squeak vm was a pre-cog one. Eliot Miranda is working on a new bytecode set/image format for 64 bits. Once that’s finished, I’d assume Pharo, Squeak and Newspeak will migrate to that.
A 64 bit image might run slower than a 32 bit one, but that is probably by nearly a constant factor, and therefore getting less and less relevant as computer speed keeps growing. More important is that being able to use large amounts of ram allows the developer to make time-space tradeoffs. That is, between his time and the cost of ram. 4GB costs less than an hour of engineering time in Western Europe and the US.
When using the larger immediate objects (smallints up to 2^62/63, smallfloats?) the 64 bit images can be faster. Gemstone has collection implementations that scale a lot better, the original implementations use a single array as backing store. For large collections you need at least array of array as backing store.
I’ve done some data conversions where I’d strongly prefer to load all data in the image and then start analysing, transforming, cleaning, and exporting it. Working from disk slows the process down by a factor of 100. That reduces feedback cycles from minutes to hours or days. The feedback cycle is crucial, especially when starting the process, as I don’t know enough about the system by then. Later in the process I might be able to partition it, but that assumes knowledge that simply isn’t there.