Related
I just read about a G1 getting a LinPack score of about 3.5ish. Most of the nearly 100% improvementwas attributed to using a rom with JIT. Since the G1 is very similar to the Vogue shouldn't we be able to get similar results.
I am currently getting 1.65.
D
-------------------------------------
Sent via the XDA Tapatalk App
If you thinks that's impressive, you should check out the new Froyo 2.2.
The Nexus One, which has 2.1 got a scrore of 6.5-7 MFLOPS, but with 2.2 it got 37.5 MFLOPS! That's an incredible performance increase.
I want 2.2, the G1 owners can keep their JIT compiler. Them fancy pants people. BTW, the article says that the HTC Hero averages a measly score of about 2 MFLOPS, so us getting 1.65 isn't bad. Though why the Nexus One gets 37.5 MFLOPS with 2.2 makes me wonder. It could be that 2.2 uses the FPU that's in the SnapDragonl, instead of the interger. If that's the case then our devices can only ever do ~1.65, cause they don't come with a FPU processor.
Though if JIT does give G1 owners a boost, then it'll certainly give us a boost. G1 doesn't have a FPU either. I'm also concerned about the 3D accelerator, as we get bad performance in some tests.
The G1 and Vogue share the same chipset--although their CPU is clocked at 528 Mhz, and ours at 400 (at least natively, that is.)
That probably accounts for the difference of 1.65 vs. 2 MFLOPs result.
If the Linpack test is to scale across all platforms, and we estimate an average 400% improvement in floating point performance, we can probably expect 6-8 in terms of a MFLOPs score on Linpack with Froyo.
Real-world applications (integer arithmetic) will not benefit nearly as well as FP arithmetic, because FP arithmetic is incredibly burdensome. However, perhaps an expected improvement of.. 100%, or 2x, is reasonable (depending). Programs with small rapid loops, etc. will see the most benefit. It'll be interesting to see how the Vogue performs.
In regards to graphics / the Vogue GPU:
I'm not completely up to speed on it, but I believe a primitive driver does work for OGL 1.0-based acceleration (Neocore?) but that's it; nothing more than 1.0 (which would explain why Live Wallpapers do not accelerate properly/crash, etc.)
I was under the impression the chipset between the Vogue and the G1/Hero/Eris was the same, and that if we simply used the driver from the G1/Hero/Eris's 2.1 ROM, we'd have full 3D acceleration.. but I don't think that's the case. There's plenty of smarter individuals here who would've ascertained the same thing, but nothing available.
I think (from a GPU perspective) we have official OGL 1.0 support and that's it.
The Kaiser, like the Vogue, uses the 400 Mhz Qualcomm chip. The difference between the chip in the Vogue/Polaris/Kaiser and devices like the G1 is Mhz and small changes done to the ATI accelerator. Though, I don't think the changes for the accelerator are major.
I have no idea about our Android setup. Is it using open source drivers? Is it using a driver taken directly from another Android device and modified, like from the G1?
I also wondered about the battery life using Android with 3D acceleration. Since Android is linux and linux open source graphic drivers are horrible and usually don't have any power management, could it be our poor battery life is due to the graphics driver?
Could it also be that the graphics driver from the G1 would work on our devices, but is a proprietary driver, and therefore can't be distributed? So instead we use open source drivers to avoid legal action?
If anyone knows the answers to these questions that would be great. I'm trying to wonder why my Kaiser with Android uses more battery life when not in use. Browsing the web or talking on the phone the battery life seems normal, but it's when it's idle that it consumes power twice as fast as Windows Mobile. To me it seems something isn't totally off when the device is in standby, and I'm thinking it's graphics related.
I've tested JIT enabled dalvikvm's on both Donut and Eclair. I never saw any noticable improvement in speed. I did however observe longer boot times and odd behavior from heavy memory intensive applications. For example, the browser sometimes doesn't launch when you have clicked it.
Give the JIT dalvikvm a try. Let me know if you experience anything positive on our vogues.
Here's a post for the G1 that uses JIT.
licknuts said:
The libdvm.so that t3steve cross compiled for the DROID at the time was for Android 2.0, the library works for with newer ROMs Android 1.6 that have some eclair pieces built into the kernel, CyanogenMOD has been using bits and pieces for a while now, if other ROM builders have been using his kernel and framework than a good chance it will work for your phone as well.
Click to expand...
Click to collapse
So, does that mean we just need eclair based roms, or is there more to that?
Dukenukemx said:
Here's a post for the G1 that uses JIT.
So, does that mean we just need eclair based roms, or is there more to that?
Click to expand...
Click to collapse
Eh, I'd just wait for Froyo, for an official JIT system designed specifically for use with the native apps in Froyo as well. Running an unofficial JIT compiler with older apps may cause some problems/force closes.. who knows.
Dukenukemx said:
I want 2.2, the G1 owners can keep their JIT compiler. Them fancy pants people. BTW, the article says that the HTC Hero averages a measly score of about 2 MFLOPS, so us getting 1.65 isn't bad. Though why the Nexus One gets 37.5 MFLOPS with 2.2 makes me wonder. It could be that 2.2 uses the FPU that's in the SnapDragonl, instead of the interger. If that's the case then our devices can only ever do ~1.65, cause they don't come with a FPU processor.
Click to expand...
Click to collapse
Without JIT (multiple test runs):
~ 1.65 MFLOPS for first 15 mins or so after startup
~ 2.33 MFLOPS after 15 mins after startup
Time to enable JIT and possible problems with apps, etc. it may cause probably isn't worth it to me.
You guys should check out this thread made by garringm from the Kaiser forum, if you wanna enable JIT. It should work, considering Kaiser users are using Vogue Android builds.
You'll need the Android SDK installed on your PC. Works with Incubus26Jc's Super Eclair and mssmison's CM 5.0.7 test 3. I ran linpack and got 3.3 MFLOPS.
I find at least for our vogues, linpack is not the best thing to judge by. It more calculations based which in most cases doesn't judge load times and the agility of our applications.
As I mentioned, I've used jit on a number of Donut and Eclair roms and although linpack may report a higher score the user experience in the speed dept wasn't improved.
Infact I found app load times to be longer with a jit enabled dalvikvm.
Are you sure the linkpack score isn't acting as a placebo?
Part of the issue is using (an unofficial) JIT compiler on a system not truly designed for it.
Froyo's compiler (along with Froyo's system) are designed to work with and efficiently use the new compiler, which means the best performance (and user experience) is going to come with Froyo, not Eclair/Donut/Cupcake with an unofficial JIT compiler.
I think we should just be patient--Froyo will be out soon, and we will surely port it to the Vogue, which will answer all of our questions.
myn said:
I find at least for our vogues, linpack is not the best thing to judge by. It more calculations based which in most cases doesn't judge load times and the agility of our applications.
As I mentioned, I've used jit on a number of Donut and Eclair roms and although linpack may report a higher score the user experience in the speed dept wasn't improved.
Infact I found app load times to be longer with a jit enabled dalvikvm.
Click to expand...
Click to collapse
Yes, the load times of applications are longer. Especially when applications are already loading slowly, this certainly doesn't help.
Are you sure the linkpack score isn't acting as a placebo?
Click to expand...
Click to collapse
Linpack is probably correct, as are the delays. I've played with emulators in the past, and I understand a bit about JIT. JIT is related to dynamic compilation, which a lot of emulators used in the past. Modern emulators like Dolphin uses JIT.
The idea is that instead of compiling data interpretively, it does it all in one shot, before the program executes. That way the program runs like it was made natively for the hardware. It would make sense that the applications have a delay in execution with JIT.
G1 owners don't have a problem with this since applications launch instantly on their phones. Running JIT for them makes no tangible difference. For us it's worse because we already have a 2-10 second delay to execute applications. This just makes it worse.
Another thing to consider is that many applications don't use MFLOPS, which is the FPU we don't have. Only 3D applications use that, and we don't use many of those. At least not yet. I'd like to try Quake 3 with it and see how it runs.
Anything better than JPC froyo?
Sliced Bread?
No. Its the best IMO and I've tried 3 2.2 firmwares. With any luck Samsung will release the official one this month.
I hope so.
Jm7 is way better
Sent from my GT-I9000 using Tapatalk
my question is how come on the current froyo roms the linpack scores don't jump much... on the desire and nexus get somewhere in the region of 40 mflops...
Is it just cause they haven't properly optimised jit on the SGS yet?
Toast?
Sent from my GT-I9000 using XDA App
Sorry the HK 2.2 is by far better than JPC...
Ibanez33 said:
my question is how come on the current froyo roms the linpack scores don't jump much... on the desire and nexus get somewhere in the region of 40 mflops...
Is it just cause they haven't properly optimised jit on the SGS yet?
Click to expand...
Click to collapse
In another thread i pointed out the same thing as you are, because i read somewhere else that HTC had to do very little job to optimize JIT for Snapdragon, having google done that with AOSP.
They replied to me saying that first Froyo FWs for Desire and N1 reached ~ the same jump from Eclair Build: 8 to 14 Mflops. Only later, with progressively better setup, they reached the 40 Mflops zone.
It could also be that JIT, the feature that most of all power up Linpack benchmark, is completely disabled in Froyo builds like JPC. I asked how we could check this, but no-one answered properly to that until now.
I've just upgraded from JM2 to JPC and for sure JM2 is better. JPC has poor responce on finger gestures and is sometimes slow. I hope these problems are solved in the final release. I'm downgrading today!
clubtech said:
Sorry the HK 2.2 is by far better than JPC...
Click to expand...
Click to collapse
Care to elaborate and cite the differences?
Stefanauss said:
In another thread i pointed out the same thing as you are, because i read somewhere else that HTC had to do very little job to optimize JIT for Snapdragon, having google done that with AOSP.
They replied to me saying that first Froyo FWs for Desire and N1 reached ~ the same jump from Eclair Build: 8 to 14 Mflops. Only later, with progressively better setup, they reached the 40 Mflops zone.
It could also be that JIT, the feature that most of all power up Linpack benchmark, is completely disabled in Froyo builds like JPC. I asked how we could check this, but no-one answered properly to that until now.
Click to expand...
Click to collapse
Oh right.. I assumed JIT was enabled but poorly implemented. 14 Mflops without JIT it pretty good! can't wait to see what happens.. Can't wait for a better leak or a proper release..
Ibanez33 said:
Oh right.. I assumed JIT was enabled but poorly implemented. 14 Mflops without JIT it pretty good! can't wait to see what happens.. Can't wait for a better leak or a proper release..
Click to expand...
Click to collapse
JIT is enabled in JPC. We might see a 20 in the final release if we're lucky, but definitely nothing more than that. The Snapdragon phones apparently have a dedicated FPU which enable them to reach such ridiculous scores. Droid X, Droid 2 and all other 1GHz non-snapdragon phones get sub 20 linpack scores on Froyo.
Sent from my GT-I9000 using XDA App
ed10000 said:
JIT is enabled in JPC.
Click to expand...
Click to collapse
How do you know that for sure?
It's a proper question, it's not that i don't believe you.
Stefanauss said:
How do you know that for sure?
It's a proper question, it's not that i don't believe you.
Click to expand...
Click to collapse
I didn't think it was.
EarlZ said:
Care to elaborate and cite the differences?
Click to expand...
Click to collapse
- Does not mess with you efs folder. That alone makes the HK version a winner.
- Excellent GPS reception and lock.
- Excellent battery life
- No lag
- I only had ONE FC with the HK JP2, unlike JPC.
Stefanauss said:
How do you know that for sure?
It's a proper question, it's not that i don't believe you.
Click to expand...
Click to collapse
There are messages about it in the log e.g.
I/dalvikvm(18078): Jit: resizing JitTable from 8192 to 16384
D/dalvikvm( 2477): JIT code cache reset in 5 ms (1048428 bytes 19/0)
we'd need samsung to optimize the jit for their hummingbird, while it might not reach N1 scores it could probably get quite a bit better
but having seen how good samsung code is, well, that just isn't happening
ps: i agree i got less issues with jp2 hk than jpc as well, especially the lags and FC's and *battery life* (it's like double time)
I've been running JPC for 5 days now, and it's great. I have no desire to switch back to an Eclair rom. I still don't have a lag fix installed and don't feel I need to. I'm also not getting any FCs at all.
What's the deal with everyone wanting massive Linpack scores anyway? What software requires that grunt? Movies run perfectly, games are fast, and most other software wouldn't even touch the capabilities of either the Snapdragon or Hummingbird processors.
If it's a pissing contest you want to win against an N1 or Desire owner, simply load up Real Football 2010 and show them how comically fast it is, since it was written for their phone and no frame limiter was appied.
For me it's not about the benchmark per se.
JIT is one of those great Froyo features, and it can massively impact performance (it's clear, for instance, that Snapdragon vs Hummingbird architecture has very little percentage impact on Linpack, it's all about JIT optimization, like 15 to 40 just tuning JIT), not just in some pointless floating point benchmark.
Nevertheless, JIT is an issue where Samsung has to put its hands on code-wise, and they definitely proved during this childhood of this phone that they can very very very much suck at that.
So this benchmark could be helpful to understand how much effort Sammie is putting into Galaxy S Development, maybe.
Question: Why Galaxy S seem to run slower in Android 2.2 (Froyo)?
I been google-ing via the net for the answer. But I can't find any answer for it.
I saw in smartphonebenchmarks.com, the quadrant scores drop from 2220 to 980.
While other phones scores seem to improve after the update.
Thanks
The galaxy after froyo update is not slower compared to the eclair version but still has long way to go. Quadrant score earlier probably would have been achieved after applying third party lag fix like voodoo lagfix.
Enspade said:
The galaxy after froyo update is not slower compared to the eclair version but still has long way to go. Quadrant score earlier probably would have been achieved after applying third party lag fix like voodoo lagfix.
Click to expand...
Click to collapse
oh ok thx.. but any idea if what would the score like after lagfix is installed?
Forget about benchmark scores, they mean very little if you don't know what they are testing.
Mine is lagging more after official unbranded update as well.. I read that restoring system settings from eclair may be an issue, but there are too many red herrings..
I tried to get information about backup/restore process before updating, but too many opinions and not enough facts..
We need an official guide that traverses smoothly from eclair, including b/r of apps, data and settings..
Samsung seems to forget we used these phones for months and do not want to begin again from factory settings.
XDA has too much info for the average users to make decisions from.
Maybe I will spend the weekend working it out..
Sent from my GT-I9000 using XDA App
Since you are talking Quadrant-wise.
Applying LagFix on Eclair had a greater effect over the I/O than it does on Froyo.
In Eclair, the I/O with LagFix gets over 7000 score in Quadrant Advanced. Under Froyo, it gets right under 4500.
On the other hand, the CPU score has risen from 900~ to 1300~ from Elcair to Froyo.
Hello!
I recently updated my Galaxy A from 2.1 to 2.2 Froyo. I was expecting that I will become a bit faster because of the JIT compiler thing.
But instead I experienced it to be much slower in overall response.
I did some research and found that for the same hardware and OS the Nexus one gives better results than Galaxy S.
Does this mean that samsung has not done a good job in writing their Froyo update for Galaxy A and Galaxy S. Or should I format my cell to factory settings to get better results?
Thanks
Do more research!
Hardware is not the same at all
JIT is optimised for Snapdragon (N1) not Hummingbird (SGS)
You should alway revert to factory settings after a major update (like froyo) for better results
Simple poll. I am curious to see who uses JIT and who has it disabled? If you answer, please explain why you do or do not use JIT. Just thought I would get people's different input on this
i used to have it enabled but had seen no positive outcomes, just more lag.
but that was when i was running CM6... i havent tried it on CM7 yet.
I know JIT on Sense 2.1 was disastrous for the most part. Have stayed away from it for the most part.
JIT on CM7 is actually very stable, however I observe absolutely no improvement or noticeable change in performance anywhere.
Then again, people also claim a smoother experience when "Allow purging of assets" is unchecked, even thought it is meant to improve performance of low memory devices like ours... YMMV, I guess.
My question is, what are the supposed benefits? Scoring higher on a particular benchmark score and thats it? I agree. It doesn't seem to make my phone any smoother, if anything, it makes it more laggy.
I've been using jit since the days of Ic3 rom and damage's roms as well. I think it just improves data. No speed on the phone just how the phone complies data. I think. But from my time on here if you can't overclock to 768 and run stable then I'd recommend avoiding jit.
Yea its Me Again With The
Modified Hero
In aosp 2.2 I would get an extra 20 or so on my quadrant score with JIT enabled. In gingerbread I haven't seen any improvement at all. I leave it disabled because I heard it uses more ram to speed things up.
I use JIT and I always have since installing custom ROM images. There's a lot of hearsay left over from long before I joined xda-developers that says it causes instability. But this is probably more to do with the original way JIT was brought to the Hero.
The latest official software for the Hero is built from Android 2.1. JIT was not introduced into Android until 2.2. So as far as I know, the original method to implement JIT on the Hero was to hack it into the official software. This is likely where the instabilities were found.
I've been using JIT since dabbling with CM6 (and its derivatives), and I've never seen any negative effects. I do, however, always decrease my VM heap to 24m and enable compcache at 18% when using JIT. Not doing so MAY cause JIT to starve the phone of memory, which could be another source of the instabilities you've seen mentioned.
Some people say JIT isn't necessary because its effects are only noticed in benchmarks such as Linpack. This, simply put, is false. JIT is always going to offer a performance increase. Now, depending on how you use your phone, the increase may not always be very noticeable, but that doesn't mean it's not there. And the less time the VM spends using the processor, the more battery life you're going to see. That's an angle that isn't always addressed when JIT is discussed.
My advice is to leave it enabled as long as you don't specifically see any issues with it. Our sister phone of sorts, the Droid Eris, now has it enabled by default in CM7.
Thanks jasonmaloney, I always prefer hearing answers from people with technical know-how such as yourself. On a CM performance related note, what is your opinion on people reporting better performance with "Allow purging of assets" disabled?
c00ller said:
Thanks jasonmaloney, I always prefer hearing answers from people with technical know-how such as yourself. On a CM performance related note, what is your opinion on people reporting better performance with "Allow purging of assets" disabled?
Click to expand...
Click to collapse
I was actually the one who submitted the patch to enable it by default. I've only ever heard of specific issues in relation to ADWLauncher, which, in my opinion, shouldn't ever be used in the first place due to the numerous better-written alternatives.
But I'm starting to wonder whether it has anything to do with the GPS problems people have been seeing.
All I really know for sure is that the graphics subsystems in CM7 for the Heroc are screwed up, and that they're probably going to be that way even when CM7 is finalized.
EDIT: If anyone can find compelling evidence that having it enabled is causing issues, I'll revert the patch and make it disabled by default.
jasonmaloney said:
All I really know for sure is that the graphics subsystems in CM7 for the Heroc are screwed up, and that they're probably going to be that way even when CM7 is finalized.
Click to expand...
Click to collapse
Is that a good or bad thing? Yes the words used dictates it's meaning, but what would have been the plus factors if it were squared away?
oohaylima said:
Is that a good or bad thing? Yes the words used dictates it's meaning, but what would have been the plus factors if it were squared away?
Click to expand...
Click to collapse
The most glaring example of a problem is seen in running Neocore. None of the textures show up.