[MLton-user] timing anomoly

[Dave Herman]

If I've understood you correctly, would it not help to perform multiple 
inlinings for multiple rounding modes and inline a conditional that 
chose the correct answer based on the current rounding mode? I'm 
perfectly ready to believe that would *not* be an improvement since 
branches are so expensive in modern hardware, but if it's still faster 
than the FP computations it could be a win.

Dave

Matthew Fluet wrote:
> 
> Good point.  Due to prompting from a user ;-), MLton carefully doesn't 
> do constant folding or common subexpression elimination on floating 
> point operations, since that wouldn't respect the rounding mode.  
> (Actually, in this situation we could do better, since it would be 
> acceptable to do CSE on the straight-line code where there are no 
> intervening calls to change the program rounding mode state.)
> 
> On Tue, 4 Dec 2007, Sean McLaughlin wrote:
>> Oh, I'm sorry!  Thanks for this.  It was keeping me up at night.
>>
>> On Dec 4, 2007 2:12 PM, Vesa Karvonen <vesa.a.j.k at gmail.com> wrote:
>>> On Dec 4, 2007 6:48 PM, Sean McLaughlin <seanmcl at gmail.com> wrote:
>>>> Fair enough :)
>>>>
>>>> However, is it possible to make this code run faster?  It currently 
>>>> runs
>>>> over 3X slower than the equivalent C program:
>>> [...]
>>>
>>> I compiled the code snippets with both MLton and gcc (-O2) and
>>> inspected the generated assembly code.  What is happening here is that
>>> gcc eliminates most of the floating point computation.  Note that all
>>> of your "x" variables are constants.  You should read the "x" values
>>> from some run-time input for a more meaningful benchmark.
>>>
>>> -Vesa Karvonen
>>>
>>
>> _______________________________________________
>> MLton-user mailing list
>> MLton-user at mlton.org
>> http://mlton.org/mailman/listinfo/mlton-user
>>
> 
> _______________________________________________
> MLton-user mailing list
> MLton-user at mlton.org
> http://mlton.org/mailman/listinfo/mlton-user