Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmarks #21

Open
NikitaMishin opened this issue Sep 28, 2021 · 5 comments
Open

Benchmarks #21

NikitaMishin opened this issue Sep 28, 2021 · 5 comments
Labels
question Further information is requested

Comments

@NikitaMishin
Copy link

NikitaMishin commented Sep 28, 2021

Do you have benchmarks for measuring the performance of double/float against fpm? Or plan to add this.

P.S is the fpm can be automatically vectorized by the compilers

@MikeLankamp
Copy link
Owner

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?

@MikeLankamp MikeLankamp added the question Further information is requested label Sep 29, 2021
@NikitaMishin
Copy link
Author

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
Copy link
Author

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

@mdragon159
Copy link

@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 =)

@mdragon159
Copy link

mdragon159 commented Oct 23, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants