[racket-dev] extflonum unboxing, f80vector ffi

Mathew,

Thank you so much for merging Michael's patch and fixing
the shuffling of the unboxed arguments. Now it all works fine
for us, including the FFI support (_longdouble, f80vector).

Michael is now working on the following:

1. Minor issue: broken contract does not check for some
reason related to the unboxing machinery:

(require racket/extflonum)

(define (a b)
   (extfl+ b 1.0))

(a 1.0t0)

Should raise "extfl+: contract violation", but silently returns
NaN instead. If one puts (extfl+ 1.0 b) instead of (extfl+ b 1.0),
it works fine. If one turns off the unboxing (by undefining
USE_EXTFLONUM_UNBOXING), it works fine too.


2. Windows build. Since MinGW is hard, Michael thinks to
give Visual Studio a try, by implementing long doubles
with inline assembly.

Best regards,

Dmitry Pavlov
Institute of Applied Astronomy, St. Petersburg

On 02/15/2013 11:39 PM, Matthew Flatt wrote:
> Merged - thanks!
>
> I'm not certain why the example below didn't work for you, but I think
> it had to do with shuffling unboxed arguments to `loop'. Please check
> whether the current version works; it now works for me.
>
> There was a mismatch in the order that unboxed arguments are gathered
> for the call and the order that they're expected, and that mismatch
> made shuffling the arguments complex. Now, unboxed arguments are
> accumulated directly to the right order in memory, and
> generate_fp_argument_shuffle() is replaced by a simple
> generate_fp_argument_shift().
>
> At Fri, 15 Feb 2013 13:44:38 +0300, Michael Filonenko wrote:
>> Hi all.
>>
>> This time I use the github pull requesting tool, which is more
>> comfortable for annotation, I think.
>>
>> The following merge request https://github.com/plt/racket/pull/245 contains:
>>
>>    * small fixes for extflonum arithmetic: two functions were not jitted.
>>    * experimental extflonum unboxing
>>    * f80vector type for ffi (sorry, not documented yet)
>>
>> I used the extfl flag and therefore did much less copypaste than previous time.
>>
>> Unfortunately the extflonum unboxing is not stable and is disabled by default.
>> You can uncomment USE_EXTFLONUM_UNBOXING definition in jit.h to turn
>> on extfl unboxing.
>>
>> The following test case fails all the time:
>>
>>    (require racket/unsafe/ops)
>>
>>    (let ()
>>      (define f (lambda (x)
>>                  (collect-garbage)
>>                  (let loop ([a 0.0t0][v 0.0t0][n 1000])
>>                    (if (zero? n)
>>                        v
>>                        (if (odd? n)
>>                            (let ([b (unsafe-extfl+ a a)])
>>                              (loop b v (sub1 n)))
>>                            ;; First arg is un place, but may need re-boxing
>>                            (loop a
>>                                  (unsafe-extfl+ v x)
>>                                  (- n 1)))))))
>>      (let ((res (f 1.0t0)))
>>        (when (not (equal? res 500.0t0))
>>          (printf "error extfl ~a~%" res))))
>>
>> If the (collect-garbage) call is removed, then the test can pass (or not).
>> My hypothesis is that the gc collects unboxed extflonums as garbage,
>> which pollutes the memory and breaks further calculations.
>>
>> Other than that, I ran out of ideas. I continue exploring the gc,
>> but an advice would be of great help. How do you think, what other
>> reason could it be?
>>
>>
>> --
>> With best regards, Michael Filonenko
>> _________________________
>>    Racket Developers list:
>>    http://lists.racket-lang.org/dev
> _________________________
>    Racket Developers list:
>    http://lists.racket-lang.org/dev
>
>