The one and only mysterious change was the fact that every component compiled as target thumb (major portion of an android) has been optimized for speed (O3) in build #1 (experimental), and optimized for size (Os) in build #2 (normal behaviour). Both builds have been compiled with the same toolchain, same version, same commits. I gave both mysterious builds and didn't tell my users what is the mysterious change. I kept that in mind and provided community with JustArchi's Mysterious Builds for test. We can't tell if things are getting better or worse according to a simple benchmark. Android is not a freaking benchmark, it's operating system. As you can see O3 > O2 > Os, Os performs about 2.5x times worse than O2, and about 3.0x times worse than O3.īut, of course. Source code of this test is available here and you may download it, compile for our beloved Android and try yourself. I set CPU to performance, maximum frequency, and I repeated each test additional two times, just to make sure that Android doesn't lie to me. I've made countless tests to find out what is the most efficient in terms of GCC optimization, two selected tests I am about to present you right now.Īs you may noticed, I compiled whetstone.c benchmark using three different optimization flags - Os, O2 and O3. As or now, we have plenty of space, plenty of ram, plenty of CPU power and still good old Os flag for 90% of Android. Os was good back in 2006, as only with this flag Google was able to compile Dalvik and it's virtual machine while keeping good amount of free memory and space on eMMC cards. Unfortunately, I proven that it is a myth. Some guys think that Os is better than O2 or O3 because smaller code size is faster due to better fitting in cpu cache. Android by default is compiled with O2 flag for target ARM (about 10% of Android, mostly low-level parts) and Os flag for target THUMB (about 90% of Android, nearly everything apart from low-level parfts). sqlite3 is not compatible with Ofast's -ffast-math flag. If you want to ask if there's something more like O4, there is - Ofast, however it breaks IEEE standard and doesn't work with Android, as i.e. O3 enables all O2 optimizations and some extra optimizations that like to increase code size and may, or may not, increase performance. It also performs further optimizations to reduce code size to the minimum. Os is similar to O2, but it disables all flags that increase code size. O2 enables all optimizations that do not involve a space-speed tradeoff. We have three interesting optimization levels. However, the commit I'm about to present you is not a placebo effect, as it applies flags to everything what is compiled, and mostly important - target THUMB, about 90% of an Android. You see big "-Os" in "TARGET_thumb_CFLAGS"? This is what I'm talking about. Take a look at the most cherry-picked " O3 Flags commit". Additionally it overwrites O2 flag, which is already fast, so as you may guess, this is more likely a placebo effect and disappears right after you change the kernel. Well, while this may be true, they've applied only to low-level ARM code, mostly used during kernel compilation. You probably may heard of some developers claiming using of "O3 Flags" in their ROMs. However, this is no longer a case, and by using newest compilers and properly setting flags, we can achieve something great. As you guess, in 2006 we didn't have as powerful devices as now, we had to sacrifice performance for smaller code size, to fit to our little devices and run well on very low amount of memory. Unfortunately, Google didn't put their best at focusing on optimization, so as a result we're using the same old flags set back in 2006 for Android Donut or anything which existed back then. So, what is it about? As we know, Android contains a bunch of low-level C/C++ code, which is compiled and acts as a backend for our java's frontend and android apps. Also, as you probably noticed, this is not a something you can apply to already prebuilt ROM (stocks), as these optimizations are applied during compilation, so only AOSP roms, self-compiled from source may use this masterpiece. If you don't know how to build your own ROM from source, this is not a something you can apply to your ROM. Solving git conflicts would also be nice. You should be already experienced in setting up your buildbox, using git, building AOSP/CyanogenMod/OmniROM from source and cherry-picking things from review/gerrit. I'd like to share with you effect of nearly 300 hours spent on trying to optimize Android and push it to the limits.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |