Flonums are not unboxed properly when passed to foreign procedures/ftypes

[williewillus]

I have this code to draw a ring using raylib: https://git.sr.ht/~williewillus/thdawn/tree/bb3ebf2b4b49d20b8fe235a6c1f5f23b8c88b0a8/item/main.ss#L1861

It's numeric all around, all the inputs are flonums besides texture (an ftype) and rgba (currently unused).
The raylib: calls are all foreign procedures that take floats, except again for set-texture which takes the texture ftype and reads a fixnum out of it to forward to a foreign procedure.

When I added calls to this code to my render loop, I was surprised to see allocation pressure increase pretty sharply, I was expecting pretty minimal allocation. I'm not actually sure if the allocation pressure is due to flonum ops not being boxed, or overhead with all of the foreign calls.

I'm not too proficient at reading the Chez assembly output, and I wasn't sure if flonum optimizations have improved since #248, so I thought I'd log this in case anyone spots something easy.

[ovueby]

I suspected that I have recently run into a similar issue with SDL, and upon looking at your code, have confirmed the issue. The flonum unboxing optimization does not trigger when casting between flonums and 32-bit floats. This applies to bytevector-ieee-single-* and the internal $fptr-*-single-float functions, the latter of which your foreign Raylib code compiles to.

EDIT: It appears this has been fixed on the main branch, however, there are still some places where flonum unboxing doesn't trigger which I have yet to diagnose.

[williewillus]

Hmm, I'm using 10.1 and none of the intervening commits on master seem to indicate it'd fix such an issue. I'll try rebuilding master and seeing if the same thing happens

[ovueby]

Upon closer inspection, the main branch only fixed bytevector and flvector allocations. I have discovered multiple parts to this issue. One, storing a 32-bit float does not take advantage of unboxing and causes an allocation unconditionally. Two, the $fptr-set-double-float! and $fptr-set-single-float! do not unbox and cause an allocation,

This leads to at least two allocations per attempt to store a flonum in a float ftype, and at least one allocation for double.