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

GNUCC flag -O2 #64

Open
pelupessy opened this issue Jul 8, 2020 · 2 comments
Open

GNUCC flag -O2 #64

pelupessy opened this issue Jul 8, 2020 · 2 comments

Comments

@pelupessy
Copy link
Contributor

pelupessy commented Jul 8, 2020

Is there still a reason for gnucc getting -o2 compiler flag by default?

Setting it to -ofast really improves performance on the Pi4. I'd suggest either removing the -o2 flag or adding the info to the readme for low-performance systems.

@fgenesis
Copy link
Member

fgenesis commented Jul 8, 2020

-O3 used to miscompile a lot. Like, all the time. mingw was impossible to compile with -O3 (exe would crash as soon as you enter a map that used element collision -- which is pretty much every map except the starting map). I've seen problems on linux/gcc as well but i don't remember specifics anymore.
Since compiler support has undoubtedly improved in the meantime (it's been a few years after all) you're right, it's probably reasonable to up this to -O3 at some point.
Except: -O3 makes some assumptions that i'm not sure the code actually fulfills (keyword: strict aliasing). So this would have to be checked before. One step towards that would be to get rid of ALL the warnings (a huge pile of work) and building on VS19 with /ANALYZE and also clang+gcc on the highest warning setting that makes sense.
I'll remember to do this for the next master update, but right now i've just picked up work on the controllerfixup branch again that has been stale for YEARS and i really want to finish & merge this thing. That branch changes a lot so fixing all the warnings before that is merged would introduce a gigantic merge conflict of doom. Please don't do this to me D:

I'll keep this issue as a reminder. In the meantime go ahead and build with -O3 if that works for you.

And as a side note, about 3 years ago i started some off-repo work on improving perf on the rpi, but that was before the release of the rpi4 and i'm actually amazed how well this runs on a pi4 now even without further optimizations. So yes, proper rpi support is definitely on the list and i'd like to do more about it, but free time is SO hard to come by.

@pelupessy
Copy link
Contributor Author

pelupessy commented Jul 8, 2020

Very happy to see that Aquaria is still being worked on, regardless (^_^)/. Over here it's really close to getting good enough for playing. The areas outside of home waters run very smooth most of the time at 720x480 resolution with a modest overclock (1.75Ghz cpu, 650mhz gpu). I think I'll do some more, uh, testing to confirm this.

Speaking about warnings, the only ones (even at -o1) I am seeing are a mass of "always_inline function might not be inlinable"'s for the file miniz. That and cmake not finding the external tinyxml2 are the only things bugging me in the build process at the moment. Am I missing some huge log file or is gcc on the pi not that fuzzy?

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

No branches or pull requests

2 participants