FloatMathPlugin and -lm (libm)
Locked
 
|
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJfEfHMAAoJEAwpOKXMq1Ma1psH/2yaIMdU6YMV8ZUSRlolvsH8 jlcuxPZV/Oo0FOq+jF2moBV01WquA8vCxZKm40s7ofrac7dWuNaaWwpDg/2xiVGc p0crmTlv9FtHqTzjT3lrBMDxvOwq9oXAJUX+LaeGhNkYMbLE969m8hoRNSlDPPuk NsXowTP7PpjyZ5RB5FApRHEnBzzyHjUIksUUhedCDWQRMqebEwxmHWbq6UobcED7 zVDx04crvw2hhzhKN8+AomZXNccMTDEQ6fTVBDeP7t4/iRmxo/6MmxOKMbQJ5dIi fgYpODPPvXiAYipVx/lRXhgo5xEjQXgPjwBXKYQy8O2vJdH/0q/7r8u8k1MutbI= =lWqV -----END PGP SIGNATURE----- |
Re: FloatMathPlugin and -lm (libm)
|
|
Hi David, On Jul 17, 2020, at 11:46 AM, [hidden email] <[hidden email]> wrote:
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?
Eliot _,,,^..^,,,_ (phone)
|
|
|
In reply to this post by stes
-----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 SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJfFDRfAAoJEAwpOKXMq1MaexQH/2pWfPKgd5EJjPXFepo5QK+z czByVnHFB8IOdcz23IVNq4JDwrMTFx3X8pnIpKAsWBOcEdxnd9zidaDdSUFk9VYF lUa8ToEpMoxbVmh0+5YH96yvXGmHQr8vv2C2G5AGuzRkqMbjTgN+MZNUGEpX0PAa 5bKLe7Lrt29Y7q2v0O6JxdlHR/xbUFcT7KFgbaWKZc/vPtGxfoVm0qyshQCFO2hJ P2RN9s3NwM9t4boO3TPpQwcnD5VGOqELWDYh1LAEksif+re5WIJmw0e9w2j5izhS qJRupmIA6qtXduj+G6sDCFdSb7Q9kPqje2RHbQgo49bOC+6BD+GspMq/NWzBwMI= =kCOF -----END PGP SIGNATURE----- |
|
|
-----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----- |
Re: setting rtprio on ubuntu 18 x64 box appears to fail
|
|
Hi David, I created an issue for this: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/540
_,,,^..^,,,_ best, Eliot |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |