On 29 July 2018 at 05:55, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
thanks for this. I don't want to respond to the tests per se, but I dowant to address one parenthetical you make.
On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson digit@sonic.net wrote:
Hi,
I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit. (I recognize 32-bit is a dying breed, but nonetheless...)
I don't think it is, at least not unless underlying OSs cease to support it. Because Smalltalk has infinite precision arithmetic the 32-bit system works very well for anything that doesn't require a huge address space. Because in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should be faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth. I no longer use the 32-bit system with any regularity, but that's because the VM simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers. But in this case the application is to a symbolic processing one, but a low level bit manipulation one.
So I, and others, hope that the 32-bit system will live for a long time. The 64-bit version has its place, and in an increasing number of contexts it is required, but it can be overkill, and so there are string benefits to maintaining both. Especially since in Smalltalk we have the infrastructure to freely exchange code between the two and are much less dependent on word size than programs written in many other programming languages.
A particular case where this applies is Internet Of Things size devices.
cheers -ben