Hi, in the developersforum i read: "And in 32-bits there are only BoxedFloat64 instances. So on a 32 bits VM Floats are represented only by BoxedFloat64. On a 64 bits VM Floats are represented either by BoxedFloat64 or SmallFloat64. " i wonder whether this means, that in 32 bit systems there exist images that dont have the SmallFloat64 object. i mean, if i make a package with a method for SmallFloat64, this would not trigger an exception on a 32 bit systems if i load it on such a system, or would it? werner
Werner,
On 02 Feb 2016, at 14:25, Werner Kassens <wkassens@libello.com> wrote:
Hi, in the developersforum i read: "And in 32-bits there are only BoxedFloat64 instances. So on a 32 bits VM Floats are represented only by BoxedFloat64. On a 64 bits VM Floats are represented either by BoxedFloat64 or SmallFloat64. " i wonder whether this means, that in 32 bit systems there exist images that dont have the SmallFloat64 object. i mean, if i make a package with a method for SmallFloat64, this would not trigger an exception on a 32 bit systems if i load it on such a system, or would it? werner
It is far from a stupid question, it is an excellent question. I don't know the answer though. Maybe those classes could exist in a 32-bit image as empty subclasses of float ? I am also not 100% sure that the intention is to keep on maintaining a 32-bit variant. Sven
Hello, Both classes (SmallFloat64 and BoxedFloat64) are present on 32 bits and 64 bits by default right now. The code base is common between 32 and 64 bit images. It is possible to run a 32 bit image without the class SmallFloat64, but it is not the default behavior. There are no instances of SmallFloat64 in 32 bits and there can't be any. There are details, such as the SmallFloat64 class needs to be present to convert a 32 bit image to 64 bits with the offline converter and if the code base remains common between 32 and 64 bit images, then the specialObjectsArray will hold a reference to SmallFloat64 which needs to be updated if one removes the SmallFloat64 class. For servers and desktop application it does not really make sense any more to remove these classes in 32 bits as they represent very few kb compared to Gb of RAM for laptops and Tb for servers. The Smalltalk image is already much smaller than let's say, the JVM default runtime. In addition, most computers are 64 bits now so it usually does not make sense to release in 32 bits. On embedded devices, one can consider deploying without classes such as SmallFloat64 or LargeInteger to minimize the memory footprint. The support for such feature is not very good currently, but it is getting slowly better. It could make sense to remove such classes if you are targeting a connected object with let's say an ARM Cortex-M4. This is part of a larger problem which consists in making the Pharo Kernel modular so that we can load only part of it in specific contexts to save memory or to reduce the system capabilities. 2016-02-02 14:43 GMT+01:00 Werner Kassens <wkassens@libello.com>:
On 02/02/2016 02:30 PM, Sven Van Caekenberghe wrote:
Maybe those classes could exist in a 32-bit image as empty subclasses of float ?
that is, what i hope <g>
werner
Hi Clement, i see, thanks for this answer. werner On 02/02/2016 03:07 PM, Clément Bera wrote:
Hello,
Both classes (SmallFloat64 and BoxedFloat64) are present on 32 bits and 64 bits by default right now. The code base is common between 32 and 64 bit images. It is possible to run a 32 bit image without the class SmallFloat64, but it is not the default behavior. There are no instances of SmallFloat64 in 32 bits and there can't be any. There are details, such as the SmallFloat64 class needs to be present to convert a 32 bit image to 64 bits with the offline converter and if the code base remains common between 32 and 64 bit images, then the specialObjectsArray will hold a reference to SmallFloat64 which needs to be updated if one removes the SmallFloat64 class.
For servers and desktop application it does not really make sense any more to remove these classes in 32 bits as they represent very few kb compared to Gb of RAM for laptops and Tb for servers. The Smalltalk image is already much smaller than let's say, the JVM default runtime. In addition, most computers are 64 bits now so it usually does not make sense to release in 32 bits.
On embedded devices, one can consider deploying without classes such as SmallFloat64 or LargeInteger to minimize the memory footprint. The support for such feature is not very good currently, but it is getting slowly better. It could make sense to remove such classes if you are targeting a connected object with let's say an ARM Cortex-M4. This is part of a larger problem which consists in making the Pharo Kernel modular so that we can load only part of it in specific contexts to save memory or to reduce the system capabilities.
2016-02-02 14:43 GMT+01:00 Werner Kassens <wkassens@libello.com <mailto:wkassens@libello.com>>:
On 02/02/2016 02:30 PM, Sven Van Caekenberghe wrote:
Maybe those classes could exist in a 32-bit image as empty subclasses of float ?
that is, what i hope <g>
werner
Could somene take the time to propose a better class comments? Stef Le 2/2/16 15:11, Werner Kassens a écrit :
Hi Clement, i see, thanks for this answer. werner
On 02/02/2016 03:07 PM, Clément Bera wrote:
Hello,
Both classes (SmallFloat64 and BoxedFloat64) are present on 32 bits and 64 bits by default right now. The code base is common between 32 and 64 bit images. It is possible to run a 32 bit image without the class SmallFloat64, but it is not the default behavior. There are no instances of SmallFloat64 in 32 bits and there can't be any. There are details, such as the SmallFloat64 class needs to be present to convert a 32 bit image to 64 bits with the offline converter and if the code base remains common between 32 and 64 bit images, then the specialObjectsArray will hold a reference to SmallFloat64 which needs to be updated if one removes the SmallFloat64 class.
For servers and desktop application it does not really make sense any more to remove these classes in 32 bits as they represent very few kb compared to Gb of RAM for laptops and Tb for servers. The Smalltalk image is already much smaller than let's say, the JVM default runtime. In addition, most computers are 64 bits now so it usually does not make sense to release in 32 bits.
On embedded devices, one can consider deploying without classes such as SmallFloat64 or LargeInteger to minimize the memory footprint. The support for such feature is not very good currently, but it is getting slowly better. It could make sense to remove such classes if you are targeting a connected object with let's say an ARM Cortex-M4. This is part of a larger problem which consists in making the Pharo Kernel modular so that we can load only part of it in specific contexts to save memory or to reduce the system capabilities.
2016-02-02 14:43 GMT+01:00 Werner Kassens <wkassens@libello.com <mailto:wkassens@libello.com>>:
On 02/02/2016 02:30 PM, Sven Van Caekenberghe wrote:
Maybe those classes could exist in a 32-bit image as empty subclasses of float ?
that is, what i hope <g>
werner
participants (4)
-
Clément Bera -
stepharo -
Sven Van Caekenberghe -
Werner Kassens