Consider finding (or writing if need be) a float32 native math library

[UserAB1236872]

After writing some benchmarks today (not for this package, just dicking around with benchmarking fast inverse square root compared to Go's stdlib and such), it's become clear that the rampant type conversions are a significant performance hit. "Significant" is in relative terms, but code of the form:

float32(1.0 / math.Sqrt(float64(n)))

takes about 15.5 ns/op compared to 3.5 ns/op for float64-native. I suspected this, hence why this library generally takes a "convert as infrequently as possible" approach. However, I would consider this significant enough to be worth worrying about.

While Go's standard library is written partially in assembly, I don't think it should be too difficult to rewrite (I think most of the assembly conversions would amount to "swap a letter in the instruction names to do 32-bit operations instead"). However, I'd like to look into existing options if they exist before undertaking this.

I did find this, but the repository was deleted for some ominous reason.

[ghost]

Couldnt we just download all the files from the original math package and do a fancy find and replace for float64->float32 then fix the 2-3 other mistakes it caused ?

[UserAB1236872]

It's largely in assembly, so it's not quite that simple.

On Fri, May 8, 2015 at 12:45 PM, Olivier Gagnon [email protected]
wrote:

Couldnt we just download all the files from the original math package and
do a fancy find and replace for float64->float32 then fix the 2-3 other
mistakes it caused ?

—
Reply to this email directly or view it on GitHub
#28 (comment).

[UserAB1236872]

Granted, we could possibly do a find+replace on the assembly instructions
too, but we'd have to do a lot of testing to ensure we didn't bork
something.

On Fri, May 8, 2015 at 1:11 PM, Jeff Juozapaitis [email protected]
wrote:

It's largely in assembly, so it's not quite that simple.

On Fri, May 8, 2015 at 12:45 PM, Olivier Gagnon [email protected]
wrote:

Couldnt we just download all the files from the original math package and
do a fancy find and replace for float64->float32 then fix the 2-3 other
mistakes it caused ?

—
Reply to this email directly or view it on GitHub
#28 (comment).

[ghost]

Yeah im working on it

[ghost]

Benchmark32Sqrt 1000000000           2.52 ns/op
Benchmark64Sqrt 300000000            4.98 ns/op
ok      math32  4.786s

First results look promising

[ghost]

https://github.com/luxengine/math WIP

[ghost]

No seriously are we getting anywhere on this.

[UserAB1236872]

If you (or someone) submits a PR, I'd be happy to accept it. It should be a relatively straightforward patch to the generator code to sub your library for native match for the f32 version. I don't have time at the moment due to PhD stuff.