Benchmarks about fpm

[MikeLankamp]

Hi, https://github.com/MikeLankamp/fpm/blob/master/docs/performance.md (linked from the README) should contain what you need.

Code using FPM may be vectorizable depending on its use and the compiler; I can't make blanket statement.

Does this answer your questions?

[mdragon159]

@NikitaMishin As mentioned in issue #5, this library already supports fixed<48, 16>. I can confirm as just started using fixed<32, 32> today

On topic: I'd also like +1 for benchmarks using larger type size. In fact, I'd love a benchmark for fixed<std::int64_t, boost::multiprecision::int128_t, 32> specifically, but that's because that's exactly what I'm using and won't be benchmarking myself for a long time coming =)

[NikitaMishin]

Yep, just looking for an fixed <48,16> or fixed<32,16> and its performance. But I am not sure if the library supports this. Is it supported? I saw the closed issue but this is unclear whether or not it is supported now.

[NikitaMishin]

@MikeLankamp this one #5 (is this issue with the support of fixed<48,16> is abandoned?)

[mdragon159]

In case anyone is looking for some quick numbers, I did a quick test comparing standard fixed_16_16 vs fixed<48, 16> with int64_t and boost's int128_t in the context of my (very early phase) game.

• Context:
  • What's being used: Using my game library/simulation layer which primarily consists of a custom, not-optimized physics engine with some ECS and simple physics-based gameplay. This "sim layer" library is then used on top of vanilla UE4, with the goal being to achieve full determinism
  • Metric: How long does a single sim library frame update take to process
  • Method: Just logging metric, playing for a few seconds, then scrolling through all the numbers. All numbers below are just a quick and rough estimate
• Data

"Float" type	Range for frame update time	Est. mean
pre-fpm raw floats	~80-400us	~150us
fixed_16_16	~400-750us	~500us
fixed<48, 16> w/ boost	~4-7ms	~5ms

That's about a 10x increase in time per frame update from switching to fixed<std::int64_t, boost::multiprecision::int128_t, 32> in my specific case... which is way too slow for my needs

Edit:
Tested fpm::fixed<std::int64_t, std::int64_t, 16> and it has about the same performance as fixed_16_16 in my context