[MLton-user] timing anomoly

Matthew Fluet fluet at tti-c.org
Wed Dec 5 06:12:42 PST 2007


On Tue, 4 Dec 2007, Dave Herman wrote:
> 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.

It is only for constant folding that one would be able to act under the 
assumption of a particular rounding mode.  And that become complicated, 
because you would need to identify a (significant) constant computation 
that could be folded.

> 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
>
>
> _______________________________________________
> MLton-user mailing list
> MLton-user at mlton.org
> http://mlton.org/mailman/listinfo/mlton-user
>



More information about the MLton-user mailing list