Recently, I finished finally modifying the xperia x10 that I have and one of the greatest improvements that those guys achieved was getting a lot more processing power by enabling JIT.
So naturally after seeing it work miracles on the x10, I went to look for it on my captivate and so far have come up with nothing anywhere. I saw some discussion in the past about it but nothing beyond.
Hopefully somebody can enlighten and if such a thing does seriously want to be worked on.... Here's a thread!
Sent from my GT-I9000 using Tapatalk
FroYo (2.2) and later have Just-In-Time compilation (JIT) out of the box. There are probably a dozen FroYo ROMs on the front page alone, so pick one have fun!
From what I've read, it's been a part of the ROMs since 2.1 but it needs to be enabled. Is this the case here or am I missing something?
Sent from my GT-I9000 using Tapatalk
kr3w1337 said:
From what I've read, it's been a part of the ROMs since 2.1 but it needs to be enabled. Is this the case here or am I missing something?
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
That is one of the biggest parts of froyo is that it enables JIT...so if you run a rom that has froyo its enabled unless I'm mistaken...
Sent from my GT-I9000 using XDA App
JIT is enabled by default in all Froyo ROM's. You can check the build.prop for ****s and giggles though.
The Galaxy S won't show the kinds of scores that Qualcomm based devices will, even with JIT enabled. Qualcomm included 128-bit SIMD Floating Point extensions with Snapdragon, while the Hummingbird only has 64-bit extensions.
yes with jit we get a 60-70% improvement but a qualcom gets 300%+ in floating point operation. in modern computers there are many other factors though and quardrant cpu scores are still very high for our chip (if you use the pay version you can see the score breakdown). so dont let the linpack scores discorage you. ive gotten as high as 18.2 in linpack with some overclocking though, which isn't bad. it's not the 50+ in the qualcom phones with some mods but not bad.
So that's what the story is, thanks guys! Wondering if things could be improved beyond overclocking...
I know it can be but don't know how. Some guys are getting 25+ in linpack on there website. So there is something else holding us back a bit.
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Dani897 said:
I know it can be but don't know how. Some guys are getting 25+ in linpack on there website. So there is something else holding us back a bit.
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Click to expand...
Click to collapse
You talking about xperia x10? really 25 on linpack? I dunno if that is even possible to OC to astronomical speeds. They run on older hardware and I think most are still on 2.1.....
All Android ROMs have a JIT compiler, it literally is what compiles all the Java on the fly. Newer versions are optimized for better performance.
So the better question is do the 2.2 Froyo ROMs have the latest JIT compiler version available or does the Nexus S have a newer more performant version we can steal. More than likely it will not work with 2.2 since the Nexus S is using 2.3.
From everything I have heard the newer JIT comp versions are optimized for the Snapdragon chipset more than anything. Which doesn't do us much good.
2.2+ have the JIT. Prior to 2.2, all programs ran entirely as interpreted bytecode on an isolated virtual machine. In 2.2+, the JIT translates the most cpu "heavy" bytecode down to native instructions during execution, stores it in cache, then runs it natively on the processor in a protected mode. Dig the video below, it's an hour long but the functionality of the JIT is explained in the first 15 minutes.
^Edited the above to accurately describe the function of the JIT
http://www.youtube.com/watch?v=Ls0tM-c4Vfo There you go, dudes. JIT Demystified.
modest_mandroid said:
2.2+ have the JIT. Prior to 2.2, all programs ran as bytecode on an isolated virtual machine. In 2.2+, the JIT translates the bytecode down to native instructions just before execution, then runs it natively on the processor in a protected mode. Could be wrong, but to my understanding, that is the major difference between 2.1- and 2.2+.
http://www.youtube.com/watch?v=Ls0tM-c4Vfo There you go, dudes. JIT Demystified.
Click to expand...
Click to collapse
This is what I saw and know too. However, I believe that the compiler that we are using is rather old and has some room for improvement. The nexus S compiler working on the captivate is a possibility that could become true after the 2.3 port is finished, provided that the developers look into it.
Sent from my GT-I9000 using Tapatalk
Related
Just did a linpack scan on my JG1 flashed SGS running Lagfix and got a score of 8 Mflops. Is this is a good / bad score?
What are your scores?
8.2Mflops or so on JM5. I don't think anything other than JIT (in 2.2) is going to increase that; lag fixes certainly won't change it.
Mithent said:
8.2Mflops or so on JM5. I don't think anything other than JIT (in 2.2) is going to increase that; lag fixes certainly won't change it.
Click to expand...
Click to collapse
Sorry but I keep seeing JIT everywhere, anybody care to explain what it stands for and how it all relates to awesomeness (thanks)
fakekullu said:
Sorry but I keep seeing JIT everywhere, anybody care to explain what it stands for and how it all relates to awesomeness (thanks)
Click to expand...
Click to collapse
JIT Just IN Time
Read on..
Android Developers
Android and me
its not in xxjp3 yet ha? or is it?
Also, keep in mind that Linpack is a synthetic benchmark and doesn't accurately reflect real performance. In fact, code like Linpacks will probably receive the biggest gain from JIT (more than real programs).
I'm using the I9000XXJP2 firmware and I think JIT is broken but I've been getting scores of 13.9 mflops with the lag fix installed!
I don't think it is broken but the dalvik files are not compiled to use ARM v7, cortex a8, or neon optimization.
Sent from my SGH-T959 using XDA App
Ok, so wen I had the n1 and the evo flashing a 2.2 based rom ment 2-3 times the quadrant scores over a 2.1 based rom, but on my new fangled droid x my score only went up a hundred points or so. Is there that much of difference between the 45nm omaps n the older snapdragon? Or is the moto 2.2 leak for the x crippled some how? Perhaps w/out JIT? Is there word as to why we get jipped on cpu speed increases?
Sent from my DROIDX using XDA App
Find a way to flash custom roms. Then you'll see them jump. Until then, the stock kernal says, NO FU I TAKE MY TIME.
Quadrant is only a number and 1800-2200 is plenty high enough for me. It's not even remotely accurate or correct as far as judging processor speed lol.
If i remember right the leaked 2.2 for droid x doesn't have the JIT complier so we wont really see that big of a jump in those scores like you did with the N1 and Evo
SStudly said:
If i remember right the leaked 2.2 for droid x doesn't have the JIT complier so we wont really see that big of a jump in those scores like you did with the N1 and Evo
Click to expand...
Click to collapse
Wrong. The leaked 2.2 doesn't have Stagefright enabled by default because videos will fail to play back. It definitely has JIT.
Well i have quadrant advanced wich breaks the scores down by section and the snapdragon has its cpu score triple because of jit where as the omap only gets a slight jump, so does this mean we aren't getting jit to function properly or what?
Sent from my DROIDX using XDA App
The 2d 3d memory and i/o scores stay the same on both from 2.1 to 2.2 its just cpu that makes the snapdragon jump so drastically so id have to agree that it doest look like we got jit in the leaked 2.2 update and all the roms based on it. Or at the very least. Snapdragon makes much better use of it than the 45nm omap
Sent from my DROIDX using XDA App
From what we've been told, this was one of the earliest releases of froyo for the Droid X... the Official Droid X Froyo release is a good 2 or 3 updates ahead of what we have available now.. its very possible that in its very early alpha stages (what we have) that JIT wasent activated then.. and when the legit release comes out in its final stage, it will have everything going
We will see when the ota comes out. I wont know if I will go through with the hassel intill I know that it can be rooted and and have recovery installed.
The snapdragon has 128 bit NEON/VFP registers with floating point hardware acceleration. The omap has 64 bit NEON/VFP registers. You will not see the same boost in quadrant\linpack like the snapdragon gets with 2.2.
shep211 said:
The snapdragon has 128 bit NEON/VFP registers with floating point hardware acceleration. The omap has 64 bit NEON/VFP registers. You will not see the same boost in quadrant\linpack like the snapdragon gets with 2.2.
Click to expand...
Click to collapse
ok im by no means an idiot when it comes to computers but that one went over my head. lol
So DK28 is supposedly 2.2.1 but I ran Quandrat with the stock rom and it comes up 873, almost exactly the same as Galaxy S 2.1, leading me to believe that JIT is not in the rom. Correct?
avenger213 said:
So DK28 is supposedly 2.2.1 but I ran Quandrat with the stock rom and it comes up 873, almost exactly the same as Galaxy S 2.1, leading me to believe that JIT is not in the rom. Correct?
Click to expand...
Click to collapse
I may be wrong but quadrant:
1) Isn't the best way to base performance
2) Doesn't really show improvements that JIT provides
Download linpack if you want and your score should be around a 14 or so, compared to the 8.5-9 on 2.1
Quadrant isn't a real life benchmark, and is highly flawed. Check out Quantum's "warp speed edition" ROM for proof.
Sent from my SPH-D700 using XDA App
I got 1205 with stock dk28 but I have noticed others reporting lower scores. Variability in testing with a bad benchmark perhaps?
I've got 1839 lol... For some reason I doubt that's accurate
I did a quadrant test with a stock epic 2.1 and an epic on dk28 and the scores were pretty much the same every time. The major difference was that the Froyo epic ran the cpu benchmarks much faster but hung during the first I/O test. The 2.1 epic ran everything about the same speed and completed the whole test much faster than the froyo epic.
I also noticed this and posted in another thread...
to quote myself
I was getting around 8.3xx in 2.1, and now I'm getting 13.7xx in 2.2.
(I used the 1506bdf2e04b.update-SPH-D700_DI18ToDK28.zip renamed to update.zip method.)
Saw a video the other day showing a nexus 1 scoring 20+ on 1st run and 40+ on 2nd.. My friends Evo (with 2.2) scored @ 38 or so..
Quadrant still shows me well under all of the 2.2+ phones listed.
Click to expand...
Click to collapse
I expected a bit more of an increase..
I too am wondering if the JIT was left out of our Froyo (if that's even possible, I'm still a total nube to andriod stuff).
What exactly is JIT, does it speed the phone up?
Sent from my SPH-D700 using XDA App
Just In Time compiling...
From what I know about .Net (I'm a C# coder), it allows for compilation of the app for the specific CPU during the 1st run.
Someone please correct me if this differes from andriod's JIT...
the epic has fast computation hw between the cpu and gpu, it could be the case that the JIT benefit doesn't show in the benchmark margins.
the device is a fast one, all compared.
Some guys found a huge optimization for Linux kernel and Dalvik as well on ARM platforms. Actually it is not made by optimizing the code, but by the way GCC compiles, and it increased the performances from 30% to 100%. There is a little video of them running a benchmark on two Android development platforms, the two development platforms are the same. Here it is :
So the ROM used is the same used by the Galaxy Nexus, and Cyanogen Mod now uses it to gain these 30%~100%. What are your feelings about it ? Are you pessimistic, optimistic about the implementation for example for stock Atrix ROMs ? Or community ROMs maybe ? Also tell us if you have some news about it.
So this optimization was made mainly for the Linux kernel on ARM devices, which means it will be way more efficient on ARM computers/servers. This is a great step forward for Linux on embedded platforms. They also worked on Dalvik, so now even Android apps will run faster.
(Sorry for my grammar if I made some mistakes, just tell me I'll correct them.)
Very impressive performance increase. Looking forward to seeing these optimizations make there way into custom roms.
Can you post more info about how this works? Or a link to the original GCC discovery?
Linaro is a hot topic in the Samsung forums. Even the OG SGS (basically half the specs of the Atrix) users are begging support for it...
Sent from my MB860 using XDA Premium App
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
AkaGrey said:
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
Click to expand...
Click to collapse
how do you know that???
facuxt said:
how do you know that???
Click to expand...
Click to collapse
http://www.droid-life.com/2012/06/1...stem-performance-boosts-are-quite-noticeable/
Sent from my MB860 CM7.2 RC3 36p Radio
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
v.k said:
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
Click to expand...
Click to collapse
It may not be easy, but I got a feeling that many people from CM teams everywhere are gonna work round the clock to get this to work on their devices.
I'm definitely not a "benchmark guy", and generally shrug off those topics, but even I was blown away after watching this video...
Sent from my MB860 using XDA Premium App
Wow. Awesome!
Imagine that guy talking one on one with a girl though......
Sent from my MB860 using XDA
rancur3p1c said:
Can you post more info about how this works? Or a link to the original GCC discovery?
Click to expand...
Click to collapse
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Slymayer said:
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Click to expand...
Click to collapse
You lost me at compilation...lol
Sent from my MB860 using XDA
So they found a way to optimize compilation for arm architecture yielding massive performance boosts over current standards.. do want =D
These dudes rock.
Sent from my MB860 using XDA
michaelatrix said:
You lost me at compilation...lol
Sent from my MB860 using XDA
Click to expand...
Click to collapse
They found a way to talk to the system by saying less. Like if I would say to you, " hello, how are things in your life" but now I say, "how's things" and you understand both phrases mean the same thing. You get to the conclusion faster because you process less information but reached the same outcome. It takes less processing for the shorter phrase and improves overall response time.
Sent from my MB860 using xda premium
i don't think it'll be easy to use it for our beloved atrix, the linaro code uses a 3.2 kernel, and we're still stuck on the crappy froyo 2.6.32 kernel =/
Hi,
I´ve read that ICS has GPU acceleration for the UI implemented as a standard. Is there really a difference in smoothness compared to custom gb roms? I´m talking about the i9001. But it should be the same as with the i9000
Regards
Lekor
Can't tell the difference.
I'm on RemICS v1.2 with Devil Kernel 3.0.72. I set GPU from stock 200MHz to OC at 250MHz and I can't tell the difference. But the Kernel developer did say it may not work. Still experimental.
Afaik no big difference, although our GPU is powerful. Maybe stock ROM has other imorovements, so the boost isn't good to feel on ICS.
Samurai05 said:
I'm on RemICS v1.2 with Devil Kernel 3.0.72. I set GPU from stock 200MHz to OC at 250MHz and I can't tell the difference. But the Kernel developer did say it may not work. Still experimental.
Click to expand...
Click to collapse
GPU OC isn't same as GPU accelerated UI
And yes ICS should benefit from it..but can't really remember anyone GB times if there has been some speed gain..
Sent from my GT-I9000 using Tapatalk 2
Yeah it does, but i reckon that ICS is really unpolished with it.
Running slim with the latest semaphore and I can definitely say this is the slickest my phone has been, but that is just my opinion
Sent from the gutter, gazing at the stars
Lekor2k said:
Hi,
I´ve read that ICS has GPU acceleration for the UI implemented as a standard. Is there really a difference in smoothness compared to custom gb roms? I´m talking about the i9001. But it should be the same as with the i9000
Regards
Lekor
Click to expand...
Click to collapse
There are apks that use the gpu. In custom roms i saw that this is true on i9001
The stock browser in 2.3.6 uses GPU acceleration. There are other apps also, but not the OS UI.
In 4.0 custom rom it should work in the apps when you enable the option from the developer options.
No difference. Everything using 8 mb more ram with 200mhz GPU acceleration.
Sent from my GT-I9000 using XDA
burakgon said:
No difference. Everything using 8 mb more ram with 200mhz GPU acceleration.
Sent from my GT-I9000 using XDA
Click to expand...
Click to collapse
Bro, just upgraded my i9000 to ice and forced gpu acceleration.
Man even on the xda app itself I can see a marginal difference in smoothness.
Sent from my GT-I9000 using xda premium
it has an option force gpu rendering that uses 2d hardware acceleration in applications...and you have to set it manual...but dont know if it rly helps in smoothness i think it depends more on the rom then to have this gpu option
MrAndroid12 said:
Bro, just upgraded my i9000 to ice and forced gpu acceleration.
Man even on the xda app itself I can see a marginal difference in smoothness.
Sent from my GT-I9000 using xda premium
Click to expand...
Click to collapse
Because it's cyanogen. You can see it's even faster on cm7.
Sent from my GT-I9000 using xda app-developers app
I see an awful lot of people saying it offers no improvements. Personally, I think it does.
I keep my phone up to date as much as possible. When ICS was stable, I jumped right in. I haven't ran Gingerbread in a long, long time—but from what I remember, it had some lag. Android, in fact, was known for this lag. You couldn't read an iOS vs Android debate without this lag being mentioned (at least when Gingerbread was the newest). And I had tried everything: every lag fix, every tweak, every ROM, every kernel, governer, scheduler, OCing, UVing—I tried it all. But I still remember there being lag.
Now I'm in the present. I've been running ICS since it was stable and, quite frankly, I don't notice that lag. I mean, yes, my phone does still lag—if I'm doing something processor intensive in the background—but not like my memories of Gingerbread. Back then, it would lag scrolling through my list of apps; it would lag doing menial UI rendering without anything running in the background. That simply does not happen anymore. Not in my experiences. Not with ICS.
Granted, as I did in Gingbread, I do in ICS—I've applied every fix, every tweak, and every possible software combination that I could get my hands on. I've tried every ROM, every kernel, every setting imaginable. And I do this because I've been thoroughly impressed by the community here at XDA. This device of ours is over 2 years old now. But the software progression does not stop. We move forward as if the hardware was built just yesterday. And I have to tell you, our phone is keeping up—it really is. My phone is faster than a lot of my peers, even with some of them having much newer hardware. And I honestly don't feel I could have said any of this if I had stayed far behind with Gingerbread.
Everyone wants a new phone. It's newer, better, faster. But what they don't realize is that software can fulfill a majority of their wants. It is a continuous improvement, however gradual it may be. To not want to upgrade your software is like not wanting to upgrade your phone. And let's be honest, who doesn't want a new phone—one that's newer, better, and faster—without ever having to buy one.
I do. And that's why I update my phone. But maybe that's just me.