Support f32?

[ishitatsuyuki]

I'm currently porting font-rs to use kurbo (for some experimental purposes) and I found that kurbo is using f64 everywhere, which seems to be an unnatural choice.

I think f64 is mostly to avoid for any compute intensive scenarios; they consume more memory bandwidth and are slower on GPUs. So can we have kurbo support f32 via generics, or simply use f32 everywhere (although it would be an breaking change)?

[raphlinus]

The use of f64 in kurbo was a conscious decision, based on empirical measurement of a number of algorithms. Basically, modern 64 bit CPUs run at the same speed with f64 and f32 for scalar code. Obviously it's a different story when SIMD, and as you point out, GPUs are also different.

Using generics makes the type signatures more complex, and can also lead to code bloat (and increased compile time) if the algorithms get instantiated more than once. I saw the generics in packages such as euclid, and that was in fact a motivation for doing kurbo.

If there are algorithms that would benefit from SIMD (arclength is one example), the use of f64 for passing parameters does not preclude f32 for the internal computation. In fact, one motivation for always passing an accuracy or tolerance parameter (though it is an ergonomic papercut) is to allow less precise but faster algorithms (and internal representations) when appropriate.

Lastly, there are cases where f32 precision is inadequate. Among them is computation of scrolling for very large scroll windows. Clearly f32 is adequate for most cases, but using f64 means you don't have to worry about it or do a detailed analysis.

In sum, it is unlikely I'd want to switch to f32. If so, the argument would need to be compelling, backed by empirical data that demonstrates that the performance gains are worth the other considerations listed above.

[richard-uk1]

An option if you need f32 would be to wrap this repo in another than converted to/from f32, then replaced calls to this lib with specialized code where necessary for performance as needed (called e.g. kurbo32). Might not be worth it for the amount of work.

If we just make the number parameter generic, that wouldn't give us the ability to write specialized algorithms for each type without specialization (I think), so there would always be a preferred and less-preferred. My advice I think would be to use this lib with f64, and see if performance becomes a problem. That would be a really interesting and useful result for the future development of kurbo if you found something that doesn't perform as well as you expect.

[ishitatsuyuki]

Thanks for the response, I fully agree that f64 is as fast as f32 in many cases, and I just saw that kurbo is intended to be usable for use cases other than pixel arts, so there are cases where precision would be needed.

I will close the issue for now. As you said, should this become a bottleneck, I will come back and post the details.