[Openmcl-devel] Floating point performance

Gary Byers gb at clozure.com
Sat Jan 30 16:28:50 PST 2010



On Sat, 30 Jan 2010, Ron Garret wrote:

>
> On Jan 30, 2010, at 2:43 PM, Paul Onions wrote:
>
>>
>> On 30 Jan 2010, at 22:30, Tim Bradshaw wrote:
>>
>>> On 30 Jan 2010, at 22:19, Paul Onions wrote:
>>>
>>>> Okay, but if I don't have a SQRT instruction then how is CMUCL able
>>>> to
>>>> go so fast?
>>>
>>> My uninformed guess would be that emulating the instruction entails
>>> a trap at some point, while CMUCL probably does not even try to use
>>> it which is much quicker.
>>>
>>> (This is based on distant experience with emulating FP on processors
>>> which didn't have it, which was deeply slow.)
>>
>> I think you're right. I've just downloaded the reference manual for
>> the MPC7445 from Freescale (I think that's likely what I've got), and
>> lo and behold in appendix B we have unimplemented instructions: fsqrt
>> and fsqrts. Bugger!
>>
>> So, what's the best way forward from here? I suppose I'll have to try
>> coding something up myself...
>
> You could just compile a sqrt function with gcc and call it through the FFI.
>
> rg
>

Or exploit the fact that the authors of the OS's math libraries have
already defined #_sqrt and #_sqrtf and call those functions.  That's
pretty straightforward; dealing with FP exceptions in math library
calls is a bit less so.

(The whole idea of using FSQRT/FSQRTS instructions was to save the
cost and complexity of doing those library calls when the instructions
were implemented; it was already hard to use "fast" and "G4" in the
same sentence.  Like I said earlier, it's harder to actually use
SQRT instructions to e.g. inline SQRT calls, so the benefit of using
the instructions was pretty modest and probably didn't justify the
cost that emulation incurs on older machines.)




More information about the Openmcl-devel mailing list