-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I've noticed that in the FloatMathPlugin there is fdlibm (freely distributable libm) :
platforms/Cross/plugins/FloatMathPlugin
This refers to the platforms/Cross/third-party/fdlibm
I wonder whether the VM shouldn't be using the system provided libm (-lm).
Perhaps for Croquet or other software that depends on FLoatMathPlugin, see https://en.m.wikipedia.org/wiki/Croquet_Project a special test framework could be ran in Squeak, or perhaps as part of "./configure" configuration, to check the results, of the underlying (system) libm, so that it provides results similar to fdlibm ?
Maybe fdlibm and libm "run bit identically" on some platforms.
This is because for Croquet the goal is to have the VM run bit identically.
Using the system provided -lm would possibly result in a smaller executable, with less duplicated code (no overhead).
I'm no expert on libm, but perhaps the system provided libm is also faster.
Regards, David Stes
Hi David,
On Jul 17, 2020, at 11:46 AM, stes@PANDORA.BE stes@telenet.be wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I've noticed that in the FloatMathPlugin there is fdlibm (freely distributable libm) :
platforms/Cross/plugins/FloatMathPlugin
This refers to the platforms/Cross/third-party/fdlibm
I wonder whether the VM shouldn't be using the system provided libm (-lm).
Perhaps for Croquet or other software that depends on FLoatMathPlugin, see https://en.m.wikipedia.org/wiki/Croquet_Project a special test framework could be ran in Squeak, or perhaps as part of "./configure" configuration, to check the results, of the underlying (system) libm, so that it provides results similar to fdlibm ?
Maybe fdlibm and libm "run bit identically" on some platforms.
This is because for Croquet the goal is to have the VM run bit identically.
Using the system provided -lm would possibly result in a smaller executable, with less duplicated code (no overhead).
I'm no expert on libm, but perhaps the system provided libm is also faster.
For context see https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/383#issuecomment-62...
What we want (I think) is either the entire vm, including the FloatMathPlugin, links against the platform’s libm, or the entire vm, including the FloatMathPlugin, links against fdlibm. I don’t see much benefit in arbitrarily mixing and matching.
So then we arrive at the above message. Is the default to link against the platform’s libm, requiring a Makefile to specify BIT_IDENTICAL_FLOATING_POINT to link against fdlibm, or is the default to link against fdlibm, requiring a Makefile to specify PLATFORM_SPECIFIC_FLOATING_POINT to link against the platform’s libm?
I agree with Marcel that the latter is preferable, by default a vm provides bit-identical floating-point, building and linking against fdlibm. For the moment we have the former.
Im not too concerned about core floating-point performance. I don’t think it dominates in our usage because we have other overheads, primarily primitive invocation and boxing/unboxing. Whereas I do think that the core execution engine should be perfectly cross-platform, and floating point is the one area I’m aware of where the platform percolates up. So I think we should make it an objective that the 6.0 release vm links against fdlibm.
What do people think?
Regards, David Stes
Eliot _,,,^..^,,,_ (phone)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
For MacOS and Windows I think that it defines -DBIT_IDENTICAL_FLOATING_POINT=1:
CFLAGS:=$(CFLAGS) -DBIT_IDENTICAL_FLOATING_POINT=1
That can be seen in
./build.macos64x64/common/Makefile.flags ./build.win64x64/common/Makefile.tools
and then it adds fdlibm/libm.a:
ifdef BIT_IDENTICAL_FLOATING_POINT LIBS:=$(LIBS) $(BLDDIR)/fdlibm/libm.a endif
So I think that if you set -DBIT_IDENTICAL_FLOATING_POINT=0 on MacOS, then it stills adds fdlibm/libm.a (because it is defined as '0')
So regardless of whether you set it '0' or '1', it adds fdlibm/libm.a right ?
David Stes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
The warning/error
pthread_setschedparam failed: Not owner
is also happening on Solaris, and obviously it also prints some text, which does not really make sense on Solaris.
I have documented on the following Wiki how to get rid of this warning/error on Solaris:
https://sourceforge.net/p/solaris-squeak/wiki/Home/
I don't know how to fix the issue specifically on your Ubuntu distribution, but possibly it makes sense to - when the error happens - to print a simple:
"error: pthread_setschedparam failed: Not owner
or
"error: heartbeat thread unable to run at higher priority"
Such a simple short message would be sufficient, and then the user can try to do some research and find fixes for the specific platform, where the error happens.
I can imagine that on various Unix flavors the instructions for:
/etc/security/limits.d/squeak.conf
do not apply.
Also note that in my limited experience on Solaris, I can either fix the warning (by having threads run at different priorities) or ignore the warning, as it does not seem to make much difference ...
But it's not nice that an extensive error message is printed, certainly not when it does not apply to that specific Unix distribution.
Regards, David Stes
Hi David, I created an issue for this: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/540
On Wed, Jul 22, 2020 at 11:12 AM stes@PANDORA.BE stes@telenet.be wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
The warning/error
pthread_setschedparam failed: Not owner
is also happening on Solaris, and obviously it also prints some text, which does not really make sense on Solaris.
I have documented on the following Wiki how to get rid of this warning/error on Solaris:
https://sourceforge.net/p/solaris-squeak/wiki/Home/I don't know how to fix the issue specifically on your Ubuntu distribution, but possibly it makes sense to - when the error happens - to print a simple:
"error: pthread_setschedparam failed: Not owner
or
"error: heartbeat thread unable to run at higher priority"
Such a simple short message would be sufficient, and then the user can try to do some research and find fixes for the specific platform, where the error happens.
I can imagine that on various Unix flavors the instructions for:
/etc/security/limits.d/squeak.conf
do not apply.
Also note that in my limited experience on Solaris, I can either fix the warning (by having threads run at different priorities) or ignore the warning, as it does not seem to make much difference ...
But it's not nice that an extensive error message is printed, certainly not when it does not apply to that specific Unix distribution.
Regards, David Stes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQEcBAEBCAAGBQJfGIB/AAoJEAwpOKXMq1MaRngIAKRpp650F5wxVLLl5RI03rxY Cbog93dnnXYhEtsKr1U1+FLTfwXcvMVDEI6nTi0dUuRfUg+698yPblisUJtQzgc4 3k54aqbz36oslkJA1y+kBU9V6nv/LfvVwpz9R0fnvuGTZndZYYHMfbCcU9yfDZ6x psHJ2EQRWfT+tjXC1nVHARb2IIWfR2NtG/YoaZcuohNE342B2CHx3OisTck5tlKA Fnx1pl/G7Z4OHleSmqKUT1KkMGfMHz4VIW0t3/D2CCMOuYqXQxxOejD2mqtqhzMP 8uUqNo1TLAmTjZwY4NVt7sa2Ny2PUXhxkASOL0c3YlvB3Dp6DAYNPptFmWC48Is= =5Vgy -----END PGP SIGNATURE-----
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
stes＠PANDORA.BE