I process geometry files, and when reading geoms, I get geo::LineString<f64> by default. Then functions like EuclideanDistance, EuclideanLength return f64. Then I calculate speeds, curves, and distances.
If I were to store them, they'd occupy a lot of space. But if I'm just processing large files, will there be any speed benefit in using f32 instead? (assuming the code will work on modern amd64 architecture, which is on laptops and servers)
Well, it's basically all about the size.
You fit more data in cache when it's half the size.
You process more values per SIMD instruction when it's half the size.
If you can only process one value at a time anyway, and you're loading something like json where it's the same time regardless of the size, then it won't matter and f64 will be about as fast as f32.
This is slightly off-topic from your question, but it sounds like you are concerned about storage space. I'm guessing that your geometry descriptions don't require a great deal of dynamic range. Have you considered storing the coordinates or lengths as integers along with a multiplier to be applied to all of them, or something along those lines?
I'm not concerned about storage space. And yes, I've considered integer coordinates, but currently storage is not a priority, I'll be fine with floats.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.