Replies: 4 comments 12 replies
-
|
Afaik that should work fine as long as the user is using the same version of LLVM (should be compatible within any NDK major release) that was used to build libunityruntime.a. If it isn't, that sounds like a bug. I don't think it'd be a good thing for most library vendors since it could make getting agreement on the compiler version very difficult for the app developer, but Unity seems like a reasonable exception to me, since it already provides pretty clear guidance in which NDKs to use with each version of the engine. As an aside, r23's support window ended recently. If you're having issues migrating to r25, please let us know so we can help :) |
Beta Was this translation helpful? Give feedback.
-
|
+1 - this should be fine with the caveats @DanAlbert mentioned. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you - will see how far I can get with it! Re r25... it's a complicated topic; if it takes another month of comparing perf results and finding LLVM workarounds, then I'd rather refrain from upgrading. However the native M1 binaries are a big plus. |
Beta Was this translation helpful? Give feedback.
-
|
Btw, if you're able, we'd love to run your benchmarks as part of our own testing. Writing our own benchmark suite isn't something we've been funded for, but Unity's has certainly found interesting results over the years. Feel free to email me directly (address listed on my profile page) if that's something you're interested in. If you need a way to sell that to your boss, remind them how much easier NDK upgrades would be if we've already run your benchmarks :) |
Beta Was this translation helpful? Give feedback.
-
|
I'll see what we can do... our performance tests are built in into the code so it would be hard to extract them to use as standalone. |
Beta Was this translation helpful? Give feedback.
-
|
Fun fact:
|
Beta Was this translation helpful? Give feedback.
-
|
Any ideas why I have an LTO'ed build crashing early during init?
ACCERR without an address is weird, I compared binary sections etc but they are identical. Could it be compiler/linker flags conflicting? Or some UB which works fine until you LTO it? Suspecting static initialization order issues... |
Beta Was this translation helpful? Give feedback.
-
|
worth disabling your crash reporter and just letting the system's one have a go, see if that gets different/better results? (not least because -- if not -- that's a bug in its own right that we should look at :-) ) |
Beta Was this translation helpful? Give feedback.
-
|
@enh-google FYI yes the default crash handler was able to publish the address etc. so there's a bug in our crash handler. we were also able to find and fix a UB in our code which was causing the crash. |
Beta Was this translation helpful? Give feedback.
-
|
As a sidenote, is there any chance that you could call through to the default system-registered signal handler after you're done in yours? Unity replacing the default signal handler makes it so that crashes in games don't get funneled through pipelines that look at tombstones or modify libdebuggerd_handler, so neither Google nor vendors (Oculus in my case) will notice when they make a change that increases the crash rates for unity apps. |
Beta Was this translation helpful? Give feedback.
-
|
@jmgao this is being fixed and has a chance to make it into Unity 2023.1. |
Beta Was this translation helpful? Give feedback.
-
Awesome, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@DanAlbert finally our LTO got to a CI, and here's a crash:
happy to share the relevant contents of the response file if needed. NDK: r23b build agent: ubuntu VM, 16Gb RAM, 8 cores. |
Beta Was this translation helpful? Give feedback.
-
This looks like a traditional OOM error, so I'm not sure that there's something actionable for us (other than trying to make LLVM use less memory). Depending on the size of what you're LTOing, 16Gb may not be enough, or you might just need to have your build system run fewer concurrent memory-heavy operations like link steps. Linking is already very memory intensive, and LTO makes this worse by pushing more optimizations + needing to have all of the sources/libraries available in memory to finalize the code. |
Beta Was this translation helpful? Give feedback.
-
|
Fair enough thank you Stephen. Is ThinLTO stable enough to be used? Checked it out and it seems to work - less memory, shorter link time; however the final binary size is +500k on 27meg. I pass -Os to the compiler (except for perf critical pieces) and the linker - is it supposed to configure what LTO optimizes for? Looking at ld.lld response file (not the one we pass to clang), "-plugin-opt=O2" is there, so maybe -Os is lost somewhere or not supposed to work at all? +500k is quite an upsetting result for -Os. |
Beta Was this translation helpful? Give feedback.
-
We use ThinLTO extensively for Android's most important libraries (https://cs.android.com/search?q=file:Android.bp%20%22thin:%22), and are even trying to use ThinLTO globally in a size-reducing form (https://android-review.googlesource.com/q/topic:global-thinlto, but we are still fixing random issues re: non-exported symbols disappearing, which is why this has been landed/reverted a few times). You might have different experiences, but please file bugs if you encounter any trouble.
In general, I think that the recommendation has been to use |
Beta Was this translation helpful? Give feedback.
-
Hi!
After we've upgraded to r23b and finally switched the linker to lld (used to be bfd.ld for arm64 builds because issues!), now I'm looking into enabling LTO.
It works on my machine (c), although x86_64 build has increased in size (!) by 1%. (x86 shows best improvement, Arm gains ~1%). I haven't assessed performance yet too.
However, I have a question which is related to our workflow and a feature called "native engine stripping".
APK-size-wise, this optimization gives huge gains.
Can LTO be enabled in such a case? Does it matter if the compilation and linking happens on different machines (and maybe even different OS's)?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions