e5b335d367
Godot supports many different compilers and for production releases we have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers all do slightly different things with -ffast-math and it is causing issues now. See #24841, #24540, #10758, #10070. And probably other complaints about physics differences between release and release_debug builds. I've done some performance comparisons on Linux x86_64. All tests are ran 20 times. Bunnymark: (higher is better) (bunnies) min max stdev average fast-math 7332 7597 71 7432 this pr 7379 7779 108 7621 (102%) FPBench (gdscript port http://fpbench.org/) (lower is better) (ms) fast-math 15441 16127 192 15764 this pr 15671 16855 326 16001 (99%) Float_add (adding floats in a tight loop) (lower is better) (sec) fast-math 5.49 5.78 0.07 5.65 this pr 5.65 5.90 0.06 5.76 (98%) Float_div (dividing floats in a tight loop) (lower is better) (sec) fast-math 11.70 12.36 0.18 11.99 this pr 11.92 12.32 0.12 12.12 (99%) Float_mul (multiplying floats in a tight loop) (lower is better) (sec) fast-math 11.72 12.17 0.12 11.93 this pr 12.01 12.62 0.17 12.26 (97%) I have also looked at FPS numbers for tps-demo, 3d platformer, 2d platformer, and sponza and could not find any measurable difference. I believe that given the issues and oft-reported (physics) glitches on release builds I believe that the couple of percent of tight-loop floating point performance regression is well worth it. This fixes #24540 and fixes #24841 |
||
---|---|---|
.. | ||
audio_driver_media_kit.cpp | ||
audio_driver_media_kit.h | ||
context_gl_haiku.cpp | ||
context_gl_haiku.h | ||
detect.py | ||
godot_haiku.cpp | ||
godot.rdef | ||
haiku_application.cpp | ||
haiku_application.h | ||
haiku_direct_window.cpp | ||
haiku_direct_window.h | ||
haiku_gl_view.cpp | ||
haiku_gl_view.h | ||
key_mapping_haiku.cpp | ||
key_mapping_haiku.h | ||
logo.png | ||
os_haiku.cpp | ||
os_haiku.h | ||
platform_config.h | ||
SCsub |