My bad, forgot to change signature. [emoji52]Meanwhile what version are you on? i guess its 1.5 as stated on your signature. Would you mind to share your config?
Very good kernel like all the work that comes from @JustArchi, super smooth and very very friendly with battery.I don't understand what is special with this kernel that it gives me much better battery than Boeffla even with same configuration, maybe Archi can give me the answer [emoji4]
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...
i think most of you cant tell the difference and dont help to improve things just make more confusion....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
@JustArchi dont feed the troll. You are one of the most talented devs around xda. It's your kernel, your time and you don't own anything to anybody. But i would like to f2fs support one day. hehehe
It's the only thing that keeping me for using AK.
Cheers!
I don't want to start a war, but you're wrong mate - there's no best kernel, it all depends on the user what he expects from one.
ArchiKernel has totally different objective than boeffla kernel. Here we experiment with everything we can, in order to achieve the best possible combination. I applied a ton of deep optimizations, which increased size of the whole binary by 2 Megabytes, so it's physically impossible that it's a placebo and doesn't change anything. Kernel is a kernel, it doesn't do complicated work and flashing even the ultimately optimized masterpiece like this one may, or may not, make a difference in terms of speed. However, considering the fact that kernel is running whole the time, this is one of the most mayor things to optimize, both for performance and battery life gain.
This is one of the most cutting-edge and stable kernels currently available for SGS3. People that search for more cutting-edge features can try arter's kernel, people that look for more stable kernel, can take a look at Andi's masterpiece called Boeffla kernel. ArchiKernel is somewhere between those two. The objective is to start from stock base, apply all cool third-party features (mostly known from boeffla kernel), then optimize everything to push the whole project to the border between awesomness, and unstability.
Everybody has his/her own opinion, and you can have your own top kernels, but calling this kernel inferior to other one is a bit disrespectful, especially because you're wrong, as this is one of the most optimized kernels available and definitely is more optimized than Boeffla one, because Andi prefers ultimate stability over cutting-edge optimizations such as Linaro toolchain. As I said, different objectives. If there were really no improvement, Linaro toolchain wouldn't cause any problems. And if it does, then definitely it acts differently, tries to optimize some things much more. Code generated by Linaro toolchain is completely different to Google's GCC, and this is just one thing that differs AK from Boeffla. In 1.5.1 I pushed this project even higher by enabling -Ofast optimizations, that may cause serious problems and only beta tests will tell me if it was the right, or wrong move. First signs say that it doesn't cause problems, and these are great news because -Ofast emits NEON code, which benefits CPU by utilizing FPU which is normally not generated due to breaking IEEE 754 standard.
So, yeah, this is not a simple fork which may be compared to other kernel. This is totally different look at common things that we can improve. I'm not a big fan of customizing kernel by endusers, same as Yank555, we both think that developer knows better and kernel is a "flash & forget" rather than tweaking things some people have no idea about. In fact, STweaks support was added ONLY thanks to Moster2, which itself is a great thing as it's always nice to cooperate with other experienced developers. This is not my project, Moster2 contributions to AK are comparable to mine, he's a developer of this project same as I am, and I'm sure that he likes the idea behind AK as well.
hey loris100 talking and criticise is easy, if you can do better put your money where your mouth is and bring as a better kernel made by you, now this is real talking not bul....i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.
i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.
when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.
also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.
im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...
i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
Oh, wait! Stahp! You forgot completely about posting some ultra trust worthy antutu benchmark scores! Come on, we all, especially ahead with Archi, would love to see those neat comparison! Dat battle! This unpredictable plot!i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.
i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.
when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.
also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.
im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...
i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
Let me give you a free advice. Never ever post disrespectful comments in the thread of one of the most talented devs actively developing for s3, unless you want to unleash the wrath and anger of all the Archi/boeffla fans on you. The thing you just mentioned, it's the most diarespectful thing you could ever say in a dev's thread. Why are you comparing two different kernels having a totally different objective? Do you know that AK is the only kernel that offers R4P0 support with stock sources, which makes is fly even further. I'm not even using AK but i'm a fan of archi's work. Learn to respect. If you think boeffla is superior, keep that thought to yourself. I'm sure 99.99% of us will not be even interested what you think at all. Instead you could have said "boeffla is more stable for me, but this one is not working well, may be due to beta version or my settings." Next time, DO NOT POST DISRESPECTFUL COMMENT or believe me, many fans wills will burn you with theirs.to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...
i think most of you cant tell the difference and dont help to improve things just make more confusion....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...
i think most of you cant tell the difference and dont help to improve things just make more confusion....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...
i think most of you cant tell the difference and dont help to improve things just make more confusion....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.
i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.
when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.
also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.
im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...
i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
i tried arter97 kernel which has this 1800mhz but i cant complete a benchmark...cant overvolt...and i dont like that kernel overall.
so comon Andi.... pls add another frequency....im sure with overvolt we can get that frequency stable.
thanks.
Have not tried AD 3 exp so far, but I think it is not caused by AK 1.5.1. No lags here and cool tool shows diferent values for CPU.since 1.5.1 I have some UI lafs especially when and shortly after turning on screen. In cool tool it shows that cpu is running at 1600 MHz all the time, sometimes process system_server pops up.
Cannot tell if its AD 3.0.0 pre-experimental or 1.5.1, since I flashed them to shortly after each other to tell about that.
- Fully optimized for Samsung Galaxy S3 (-marm -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp)
- Compiled with O3 optimization level (-O3)
- Performed interprocedural pointer analysis and interprocedural modification and reference analysis (-fipa-pta)
- Performed loop invariant motion on trees. It also moved operands of conditions that are invariant out of the loop, so that we can use just trivial invariantness analysis in loop unswitching. The pass also includes store motion (-ftree-loop-im)
- Created a canonical counter for number of iterations in loops for which determining number of iterations requires complicated analysis. Later optimizations then may determine the number easily (-ftree-loop-ivcanon)
- Performed induction variable optimizations (strength reduction, induction variable merging and induction variable elimination) on trees (-fivopts)
- Tried to reduce the number of symbolic address calculations by using shared “anchor” symbols to address nearby objects. This transformation can help to reduce the number of GOT entries and GOT accesses on some targets (-fsection-anchors)
- Assumed that loop indices do not overflow, and that loops with nontrivial exit condition are not infinite. This enables a wider range of loop optimizations even if the loop optimizer itself cannot prove that these assumptions are valid (-funsafe-loop-optimizations)
- Moved branches with loop invariant conditions out of the loop (-funswitch-loops)
- Attempted to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization most benefits processors with lots of registers (-frename-registers)
- Re-ran common subexpression elimination after loop optimizations are performed (-frerun-cse-after-loop)
- Didn't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions (-fomit-frame-pointer)
- Made a redundant load elimination pass performed after reload. The purpose of this pass is to clean up redundant spilling (-fgcse-after-reload)
- Ran a store motion pass after global common subexpression elimination. This pass attempts to move stores out of loops (-fgcse-sm)
- Eliminated redundant loads that come after stores to the same memory location, both partial and full redundancies (-fgcse-las)
- Constructed webs as commonly used for register allocation purposes and assigned each web individual pseudo register. This allows the register allocation pass to operate on pseudos directly, but also strengthens several other optimization passes, such as CSE, loop optimizer and trivial dead code remover (-fweb)
- Performed tail duplication to enlarge superblock size. This transformation simplifies the control flow of the function allowing other optimizations to do a better job (-ftracer)
Linaro toolchain update, 4.9.1 -> 4.9.2, 14.07 -> 14.09
- SEA2 -> Update14 (really misc update from samsung)
- Added BFQ scheduler # Thanks to @Moster2
- STweaks: ZRAM, BFQ, Knock-on corrections, Sharpness tweak and more misc bugfixes/improvements # Thanks to @Moster2
- Added ArchiKernel logo after booting of the kernel
- Silenced some more debug informations (including touchscreen)
- Updated ZZmoove to 0.9 beta4
- Merged N8000 sources for all variants (this should fix graphical glitches for ArchiPort and other ported Sammy ROMs, AOSP also benefits from that) # Thanks to @LordBoeffla
- Fixed graphical glitches on AOSP ROMs which happened after above merge # BIG THANKS to @Moster2
- Many R4P0 fixes and improvements # Thanks to @Moster2
- Fixed sharpness tweak # Thanks to @Moster2
- Added some misc LD optimizations (-Wl,--sort-common + -Wl,--O1)
- More on github