-
Notifications
You must be signed in to change notification settings - Fork 43
Version 47.1 #11
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
base: master
Are you sure you want to change the base?
Version 47.1 #11
Conversation
https://android.googlesource.com/platform/prebuilts/simpleperf/+/refs/heads/ndk-r13-release/README.md Included in platform/system/extras, if we ever want to profile.
-Bump up to minimum API level of 14 -Drop ARMv6 and below support, only ARMv7 devices and above received ICS, so we can safely drop it and still cover well over 90% of devices -Drop CPUFamily, we'll get all the information we need from CPUType -WRITE_EXTERNAL_STORAGE is depcreated past SDK version 18 -Clean up XML tags
-Update build tools -Shift some settings from the manifest to build.gradle -Use Android Studio's built-in native compilation system -Drop sourcesets, that dir doesn't even exist
-Enable fmodulo-sched and floop-strip-mine -Remove some flags already enabled by -O3 -Add -fno-branch-count-reg for x86
Merge v47-1 to v48 Flag "-ffast-math" is already used with "-Ofast", making the flag redundant,
app/build.gradle
Outdated
@@ -1,7 +1,7 @@ | |||
apply plugin: 'com.android.application' | |||
|
|||
android { | |||
compileSdkVersion 26 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason to drop it, it's released, and allows us to use mentioned APIs without errors. targetSdkVersion is what you want to watch.
app/src/main/jni/Application.mk
Outdated
@@ -4,7 +4,7 @@ APP_STL := gnustl_static | |||
APP_ABI := armeabi-v7a x86 arm64-v8a | |||
|
|||
# For releases | |||
APP_CFLAGS := -Ofast -fmodulo-sched -fmodulo-sched-allow-regmoves -fsingle-precision-constant -fvariable-expansion-in-unroller -fomit-frame-pointer -fno-math-errno -funsafe-math-optimizations -ffinite-math-only -fdata-sections -fbranch-target-load-optimize2 -fno-exceptions -fno-stack-protector -fforce-addr -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-loop-if-convert-stores -floop-strip-mine -ftree-loop-distribution -floop-interchange -ftree-loop-linear -floop-block -Wno-psabi | |||
APP_CFLAGS := -O2 -fmodulo-sched -fmodulo-sched-allow-regmoves -fsingle-precision-constant -fvariable-expansion-in-unroller -fomit-frame-pointer -fno-math-errno -funsafe-math-optimizations -ffinite-math-only -fdata-sections -fbranch-target-load-optimize2 -fno-exceptions -fno-stack-protector -fforce-addr -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-loop-if-convert-stores -floop-strip-mine -ftree-loop-distribution -floop-interchange -ftree-loop-linear -floop-block -Wno-psabi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason for dropping Ofast? This will hinder performance a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ofast is basically O3 plus a few other things. O3 is actually a very dangerous optimization level, and even though it might bring better performance, it can also break the code.
O2 is the recommended level of optimization without risking breakage, according to the GCC manual.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naturally, a majority of our optimizations are dangerous - but they work, and they've been tested, hence why they're here. O3 is the minimum I'd recommend, it's Ofast that would truly be dangerous, but it hasn't really shown us any issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should really change that back. The Ofast thing also enables "-ffast-math", so we don't need to define that flag.
@@ -49,22 +49,22 @@ | |||
#define FLOATING_SQRT | |||
|
|||
#ifdef HAVE_NEON | |||
#if defined(__arm__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very easily avoidable by just removing -DHAVE_NEON from ARMv8, this is extra code that we don't need. Although, I don't see any drawbacks from having this enabled on ARM64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the "HAVE_NEON" from ARMv8 long ago, but that condition was still being fulfilled. That's why that line of code is there.
I'll merge this in later today -- are there any other changes for 47? |
At the moment, no. |
There actually are a few other things I'd like to push - although personally I don't think this is ready yet (just my opinion though). |
I made an APK for this. |
v47.1 also needs this
Come to think of it, I might just use the v48 branch to add 64-bit support. I can't seem to get anywhere with runtime with it because Lightning JIT doesn't like ARM64. |
I have managed to get nds4droid to operate on 64-bit devices without crashing.
|
I'm done making pushes now. Looks like 64-bit devices are not friendly to the Threaded Interpreter or Lightning JIT (in other words, they crash). |
# Conflicts: # app/src/main/jni/desmume/src/armcpu.cpp
Almost an entire month has passed since this pull request has been made. |
It has been one year and 5 days since this pull request was opened, and it's still open today. This is really nice, when you think about it. |
Any news updates about this? |
This PR will celebrate its 5th birthday this month! And guess what, it's still open! Nice. |
Lots of things are optimized here. Only the ARM binaries succeeded in compilation.
x86 now utilizes AsmJIT, but whether or not it compiles remains unknown.