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.
I've been reading a lot of discussion on this and would love to hear some opinions and see some benchmarks.
I currently own a Nexus One & where I live they are priced about $150 dollars more for a Nexus than a Galaxy S (It's my understanding Nexus are regarded as cheaper phones in America?) So basically I can sell my 4 month old Nexus One & buy a brand new 16GB Galaxy S for no extra cost. Here is what I am wondering...
I know the Galaxy S has an amazing GPU, it facerolls the Nexus One & even seems to stomp the Droid X with its improved GPU so that is great.
The CPU however seems to under perform in every benchmark I can find versus the Nexus/Droid2 & many more current high end Androids.
I realise these devices are running Android 2.2 with JIT. I've seen Linpacks of 2.2 running Galaxy S devices and JIT enabled ROMs that still don't compare with these other devices.
Question 1
What I'm wondering is the difference we can see in CPU benchmarks going to be surpassed with the addition of a proper 2.2 JIT rom on our devices or is simply that the Snapdragons & other Qualcomm CPU are actually better than our Hummingbird.
Question 2
My Nexus One is Linkpacking 30 MFlops atm, I think with OC etc I can get it higher too. Does anyone have any evidence of a Galaxy S phone (running 2.2, JIT, lagfix or anything) that competes (or even comes close to competing) with this? I have been unable to find anything.
Question 3
Is the current Quadrant scores that I'm seeing people reporting in the Lag Fix threads (2000+) actually representative of speed or are these (as Cyanogen & others seem to be claiming) distorted?
(I realise a lot of people are reporting lag fixed.. what I'm asking is the number represented there (x2 N1 Froyo's score) actually accurate. I don't understand the mechanics behind the I/O benchmark so I don't understand if the lagfix is distoring the reported results from it.)
1. Hummingbird is apparently faster.
2. We don't have JIT yet.. Compare Nexus One 2.1/Eclair with Galaxy S 2.1, and I remember seeing we are faster.. JIT has a massive impact on mflops (because the benchmark uses bytecode, not compiled code).
3. No benchmark is really representative of speeds (no matter what people tell you). Because different apps have different workloads. You might get 50mflops in a CPU test, but for 3D games, the number of triangles matters more. It has recently been shown the I/O test for quadrant can be tricked too.
Benchmarks aren't really comprehensive enough for anything more than getting an idea of the performance.. But don't rely on them.
The reason why we get crappy benchmarks is due to having ****ty filesystem (rfs) which don't let us have multi writes. That's what lag fixes help. Cpu wise we eat snapdragons for breakfast, lunch and tea.
Sent from my GT-I9000 using Tapatalk
andrewluecke said:
1. Hummingbird is apparently faster.
2. We don't have JIT yet.. Compare Nexus One 2.1/Eclair with Galaxy S 2.1, and I remember seeing we are faster.. JIT has a massive impact on mflops (because the benchmark uses bytecode, not compiled code).
3. No benchmark is really representative of speeds (no matter what people tell you). Because different apps have different workloads. You might get 50mflops in a CPU test, but for 3D games, the number of triangles matters more. It has recently been shown the I/O test for quadrant can be tricked too.
Benchmarks aren't really comprehensive enough for anything more than getting an idea of the performance.. But don't rely on them.
Click to expand...
Click to collapse
what he said ^^^
regards
ickyboo said:
The reason why we get crappy benchmarks is due to having ****ty filesystem (rfs) which don't let us have multi writes.
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
Source please.. I never have actually seen anyone prove this here, but I hear it being thrown around increasingly. How was this proven? I'm becoming increasingly concerned that this conclusion was made by playing chinese whispers
andrewluecke said:
Source please.. I never have actually seen anyone prove this here, but I hear it being thrown around increasingly. How was this proven? I'm becoming increasingly concerned that this conclusion was made by playing chinese whispers
Click to expand...
Click to collapse
Well, if you look at pre-Froyo benchmarks of Snapdragon devices, they generally get around 6.1 in Linpack, vs ~8.4 for a Galaxy S. That's a pretty big delta, and carriers through most other synthetic and real world benchmarks, roughly 20% faster at the same clock speed. Same thing can be seen with the TI processors in the Droid line, at 1Ghz, they score in the 8's with 2.1.
Froyo benchmarks are suspect for a number of reasons, mainly because most of the benchmarks were designed with 1.6-2.1 in mind, and partly because Google spent a lot of time optimizing the base Froyo build for a Snapdragon processor. HTC, Sony, Dell, etc can piggyback off this work with their version, whereas Samsung and Motorola have to start much closer to scratch. Which is also why the HTC devices got Froyo sooner.
Believe it or not (and despite the marketing hype) the Snapdragon chipset is a budget solution, with less complex/expensive memory subsystem, and a far less costly integrated graphics solution than what is found on the Galaxy S.
It's cheap to produce, it has almost everything in a nice tidy package that makes it cheaper to engineer handsets (when I say everything, I mean CPU/GPU/Radio/WiFi/GPS/USB).
It's a pretty good package for companies like HTC, who don't do any real hardware engineering, and try to keep costs low. They do software (very very well, I should add), industrial design, and mass manufacturing, but they've NEVER designed a chipset (or display), they always source those from a third party, in this case Qualcom for the chipset, Samsung/Sony for the displays, etc.
However, they were the first to market with 1Ghz speed and it's a solid and stable hardware setup. Just keep in mind that clock speeds don't tell the whole tale.
The Galaxy S, (and to a lesser extent the Droid series) use a better stand-alone CPU solution and a far superior non-integrated (has its own chip) GPU. Samsung does do their own in-house chipset engineering, and they didn't cut corners on the CPU design, and they learned a lot about how to squeeze a lot of performance out of the ARM instruction set from their own products and the work they did for the iPhone processors. In brute-force, they smack the Snapdragon chipset around like a *****, but they get slapped around in turn by HTC's superior software engineering.
HTC has a real advantage in lots and lots of PDA/Smartphone software experience. They know how to make the most of the hardware they purchase, and seem to spend a great deal of time optimizing the software, be it Windows Mobile or Android, and lessons learned from a decade of making PDAs, under their name and for others.
If HTC used a Hummingbird or TI OMAP chipset with PowerVR GPU, I have no doubt they'd be able to more quickly wring more performance and stability out of it than Samsung or Motorola can.
Croak said:
Well, if you look at pre-Froyo benchmarks of Snapdragon devices, they generally get around 6.1 in Linpack, vs ~8.4 for a Galaxy S. That's a pretty big delta, and carriers through most other synthetic and real world benchmarks, roughly 20% faster at the same clock speed. Same thing can be seen with the TI processors in the Droid line, at 1Ghz, they score in the 8's with 2.1.
Froyo benchmarks are suspect for a number of reasons, mainly because most of the benchmarks were designed with 1.6-2.1 in mind, and partly because Google spent a lot of time optimizing the base Froyo build for a Snapdragon processor. HTC, Sony, Dell, etc can piggyback off this work with their version, whereas Samsung and Motorola have to start much closer to scratch. Which is also why the HTC devices got Froyo sooner.
Believe it or not (and despite the marketing hype) the Snapdragon chipset is a budget solution, with less complex/expensive memory subsystem, and a far less costly integrated graphics solution than what is found on the Galaxy S.
It's cheap to produce, it has almost everything in a nice tidy package that makes it cheaper to engineer handsets (when I say everything, I mean CPU/GPU/Radio/WiFi/GPS/USB).
It's a pretty good package for companies like HTC, who don't do any real hardware engineering, and try to keep costs low. They do software (very very well, I should add), industrial design, and mass manufacturing, but they've NEVER designed a chipset (or display), they always source those from a third party, in this case Qualcom for the chipset, Samsung/Sony for the displays, etc.
However, they were the first to market with 1Ghz speed and it's a solid and stable hardware setup. Just keep in mind that clock speeds don't tell the whole tale.
The Galaxy S, (and to a lesser extent the Droid series) use a better stand-alone CPU solution and a far superior non-integrated (has its own chip) GPU. Samsung does do their own in-house chipset engineering, and they didn't cut corners on the CPU design, and they learned a lot about how to squeeze a lot of performance out of the ARM instruction set from their own products and the work they did for the iPhone processors. In brute-force, they smack the Snapdragon chipset around like a *****, but they get slapped around in turn by HTC's superior software engineering.
HTC has a real advantage in lots and lots of PDA/Smartphone software experience. They know how to make the most of the hardware they purchase, and seem to spend a great deal of time optimizing the software, be it Windows Mobile or Android, and lessons learned from a decade of making PDAs, under their name and for others.
If HTC used a Hummingbird or TI OMAP chipset with PowerVR GPU, I have no doubt they'd be able to more quickly wring more performance and stability out of it than Samsung or Motorola can.
Click to expand...
Click to collapse
Thanks, that was a really insightful post.
So basically even though our processor should outperform or ATLEAST match the snapdragons. Due to the mass optimization of 2.2 JIT for Snapdragon devices it's likely we'll never see the same performance. Unless Samsung gets really keen to do some optimization themselves.
I searched all over the internet to see why the CPU scores in Quadrant and other benchmarks are waaaay lower then the Nexus ones, but still I can't find anything.
Does Samsung disable the JIT in their Froyo ROMs? Because both Snapdragon and Hummingbird are still based on the same Cortex A8 cores
"It's clear that FroYo's JIT compiler currently only delivers significant performance gains for Snapdragon CPUs with the Scorpion core. This in turn explains why, so far, only a beta version of Android 2.2 is available for the Cortex-A8-based Samsung Galaxy S — the JIT compiler is the outstanding feature of FroYo. For the widespread Cortex-A8 cores, used in many high-end Android smartphones, the JIT compiler needs to be optimised. A Cortex-A8 core will still be slower than a Scorpion core at the same clock speed, but the Scorpion's advantage may not be as much 260 percent."
Click to expand...
Click to collapse
http://androidforums.com/samsung-ca...ant-scores-why-humming-bird-doing-so-bad.html
There are multiple reasons, not optimised jit, slow memory for caching and more. Most of them are solved in the CM roms (it performs on par with the N1), and i can tell you that when Gingerbread comes it will blow the snapdragons away.
Which custom ROM provides CPU performance close to Snapdragon?
[ignore this post please]
Still the 1Ghz humming bird out performs the 1Ghz snap in real world performance
Even the LG Optimus One ARM11 600MHz Core scores better than Galaxy S. I still believe it's a software problem.
http://lgoptimusonep500.blogspot.com/2011/01/custom-rom-for-lg-optimus-one-p500.html#more
Another benchmark:
http://www.anandtech.com/show/4126/nokia-http://www.anandtech.com/show/4126/nokia-n8-review-/7
...where the Nexus S proves that the Hummingbird can do more than it currrently does in Galaxy S.
I have the captivate with bloatware removed, unhelpful's overclock kernel, and the lag fix, I get quadrant scores as high as 2505. I was wondering if the phone its just that awesome or if there were similar mods to snapdragon phones that give them similar performance. i know they can be overclocked.
I guess what I'm getting at is that my phone would hang on the file system tests in quadrant until the lag fix where the score nearly tripled! Is this something unique to the galaxy s do to a flaw or are there similar problems on other phones that could be fixed and yield similar performance to my phone? Or is the galaxy s cpu, gpu and ram and other components just that much better?
Sent from my SAMSUNG-SGH-I897
My $0.02 says the galaxy s as a processing unit is slightly better than the older snapdragon. Better optimised, newer (45nm > 60nm) etc. There could very well be processing issues on other chips too. We wont know until someone finds them. Bear in mind however, the Snapdragon chips are likely to be much better optimised for android operating systems - as android is developed on that reference hardware - e.g. nexus one uses a quallcomm snapdragon and gets a massive jump with JIT, froyo. However, droid X, Droid 2 with froyo dont see nearly as high increases in performance.
The GPU is known to be significantly better on the Galaxy S phones. However, its only a matter of time before the next gen snapdragons take the lead again (or at least play catch up)....and somehow I wont be surprised if the subsequent Galaxy S 2 devices retake the lead
Pretty much what I was thinking, from what I understand the snapdragon has up to 20% greater throughput than a standard arm v7 processor but the hummingbird needs 15-25% fewer instructions to do the same task. I wish I could remember the reference for that. In other words, snapdragon works harder and hummingbird works smarter.
I knew as far a shear performance it would come down to the gpu but didn't know any details on that.
Sent from my SAMSUNG-SGH-I897
The issue that slows the Galaxy models is Samsung's proprietary file system. The lagfix improves performance by wedging in between the filesystem and providing a buffer built with a modern filesystem.
The massive score increase in Quadrant is due to the file IO being MUCH MUCH faster when the lag fix is applied. If you were to look at the professional version of Quadrant (which breaks down the scores into their categories) the File I/O portion would be in the mid to high 6000's, which really unbalances the score..
From the Greene Computing website (accessible from Linpack app), SGS scores range from 8 (Android Eclair 2.1) to 14 (Froyo).
But I see HTC and Motorola Linpack scores (Froyo) ranging from 30s to 40s.
Also does anyone know SGS Quadrant scores (with lagfix)?
Sent from my GT-I9000 using XDA App
Thats 14 PRERELEASE froyo!
But it's theorised it's due to the way SIMD is designed on Hummingbird. Linpack says VERY little about real performance anyway though.
SGS (stock eclair ROM) with OCLF 2.0 gives me a quadrant benchmark score of ~2150, which just about beats every other phone...
andrewluecke said:
Thats 14 PRERELEASE froyo!
But it's theorised it's due to the way SIMD is designed on Hummingbird. Linpack says VERY little about real performance anyway though.
Click to expand...
Click to collapse
Do you mean that Quadrant is closer to real world users experience compared to Linpack?
From published reviews, it does seem that 2D, 3D games (which is computationally intensive) are generally more fluid on SGS than HTCs
So why does Linpack really indicate?
Sent from my GT-I9000 using XDA App
Prasad007 said:
SGS (stock eclair ROM) with OCLF 2.0 gives me a quadrant benchmark score of ~2150, which just about beats every other phone...
Click to expand...
Click to collapse
Gosh, if Eclair with lagfix scores 2150, Froyo should be off the charts! Can anyone share the numbers?
Is performance gains for OCLF similar to Voodoo?
Sent from my GT-I9000 using XDA App
ckkee said:
Gosh, if Eclair with lagfix scores 2150, Froyo should be off the charts! Can anyone share the numbers?
Is performance gains for OCLF similar to Voodoo?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
bear in mind that the number doesn't tell much. You can have great number but ordinary performance.
many screen capture shared in XDA, this is one of the screen capture on I9000XWJM7 + RyanZa OCLF
http://forum.xda-developers.com/showthread.php?p=7951649#post7951649
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I believe you have the basic Quadrant ? Well, I have Quadrant Advanced, and the graph shows sections in the bars for each phone bifurcated as CPU, 2D, 3D performance, etc.. With the lagfix, our I/O section for our phones is significantly elongated (due to the filesystem changes). What do I use to take a screenshot ?
One thing to also add to the balance is that the Galaxy S also has the best GPU available for smartphones:
Here is a GPU comparison for some of the leading smartphones:
■Motorola Droid: TI OMAP3430 with PowerVR SGX530 = 7-14 million(?) triangles/sec
■Nexus One: Qualcomm QSD8x50 with Adreno 200 = 22 million triangles/sec
■iPhone 3G S: 600 MHz Cortex-A8 with PowerVR SGX535 = 28 7 million triangles/sec
■Samsung Galaxy S: S5PC110 with PowerVR SGX540 = 90 million triangles/sec
And for comparison a few consoles:
■PS3: 250 million triangles/sec
■Xbox 360: 500 million triangles/sec
Click to expand...
Click to collapse
you also have a dedicated GPU (PowerVR SGX540 GPU) and LinPack is a mathematical only benchmark, so it only test the capacity for the CPU to makes calculation per seconds (MFlops).
Where MFlops is a good indicator, the uses of multimedia applications on modern smartphone is more GPU intensive so, unless you're doing intensive database application on your phone, MFlops are juste an indication.
You can see a comparaison of the full specs here:
http://alienbabeltech.com/main/wp-content/uploads/2010/04/Cellphonehardwarecompari1.png
You can see a real life test here:
http://www.youtube.com/watch?v=dpP5QljEqow&feature=player_embedded#!
It doesn't test mflops though, it simply tests the speed of Dalvik. Similar to what Nvidia did, it is also possible some manufacturers might begin to optimise specifically for benchmarks (and we don't want that)
The Linpack CPU scores are lower than scores from Qualcomm CPUs because the Qualcomm CPUs have higher throughput SIMD FP units. This means they score higher in the linpack scores, but this does not translate to better performance on a day to day basis.
Quadrant scores with OCLF are not correct. Because of the filesystem changes, OCLF just bypasses the I/O stage of Quadrant, and scores the highest possible mark for I/O. Quadrant scores with Voodoo are a more accurate benchmark, because it actually does the benchmark, rather than just bypassing it.
Here we go again.
The Quadrant scores with the lagfixes are largely irrelevant as it does not in all cases test real world performance. To dumb it down, due to the way some lagfixes are implemented it's not actually real disk reads and writes being tested. Doesn't mean real world performance isn't improved by the lagfixes, because it is. The number in the test just doesn't mean anything. The benchmark has some use when comparing different lagfixes to eachother on the same device, but only to say which one is generally faster, not how much faster it is. Then again, when comparing OCLF to Voodoo it is again not comparable.
As for Linpack, the difference in score is due to the "FPU" (SIMD/NEON/VFP) instructions. Snapdragon (Qualcomm) has a better FPU than Hummingbird (Samsung) does. However, (again) it doesn't make that big a real world difference. Before the Snapdragon and Hummingbird devices, FPU instructions were either slow, really really slow, or emulated in software as the hardware for it was simply non-existent in the chips used. The expected performance of tests that use these instructions by Linpack is likely a whole lot lower then is now being reported by Snapdragon, with Dalvik JIT optimizations for this FPU. The part of the total score that can be attributed to the FPU is therefore blown completely out of proportion, as it completely overshadows the performance of the tests that primarily use the CPU.
Of course, yes, Snapdragon's FPU is a whole lot faster than Hummingbird's. The implied real world performance difference by Linpack is however complete nonsense.
To Chainfire, thanks for the detailed explanation on the two tests, and why the Hummingbird and Qualcomm cpus differs in scores.
From anecdotal comments in reviews (see AnandTech review on SGS devices, which I feel is more objective than most reviewers), SGS is generally regarded as the smoothest Android device amongst the current crop of 1st Ghz smart phones. This is largely based on Android UI operations and 2D/3D games performance.
Hence, I was surprised that SGS Linpack scores are so much lower than Qualcomm devices. Your insightful posting has helped to clear that up.
On the topic of SGS performance, lag fixes seem to help tremendously. Is there a compendium introducing the various lag fixes and which may be most suitable for I9000 international devices?
From reading disparate threads, it appears that OCLF came first (using Ext2 file system) followed by Voodoo (Ext 4). From the view of maintaining compatibility with upcoming Froyo and possible future fixes from Samsung (i.e. Compatibility with Kies is a must), which is the better choice?
Note, I am using stock ROM (Eclaire JG4) with ADW.Launcher. and my SGS does not support 3 button recovery mode.
Sent from my GT-I9000 using XDA App
I'm sorry to bump this old thread again, but I felt like it was a better choice than opening a new one.
It makes sense there's a difference between Snapdragons and other cores that are more closely related to the Cortex A8 like the Hummingbird and the OMAPs. But I find one thing weird:
This is a screenshot of an iPad having finished a Linpack benchmark. As you can see it's getting a score of more than 62 MFLOPS. iPhone 4's with a similar Apple A4 (albeit at a lower clock speed) are scoring around 36 MFLOPS, which I confirmed on a friend's iPhone 4 as well as internet sources. Now: the Apple A4 and Hummingbird are supposedly very related, and the biggest difference as I understand is actually the GPU, not the CPU core. So these large differences between an iPad and a Froyo Galaxy S should simply not be there.
To me, this can mean three things:
The Linpacks for iOS and Android are completely incomparable
Samsung and Texas Instruments CPUs can't take as much advantage of the JIT in Android as Snapdragons can
There is a large difference in MFLOPS performance between Snapdragons and Cortex A8's - Snapdragons would get a much higher score even when running iOS
To get a definitive answer about the Galaxy S's comparative MFLOPS performance, I think the best idea is to run a native (not using Android) benchmark on both a Hummingbird and Snapdragon (and maybe an OMAP). Could Ubuntu on a Nexus One and Galaxy S give us a definitive answer? Can anyone test?
This should be helpful for Motorola owners as well.
You can't compare them unless you do a native benchmark on Android.
DCKing said:
I'm sorry to bump this old thread again, but I felt like it was a better choice than opening a new one.
It makes sense there's a difference between Snapdragons and other cores that are more closely related to the Cortex A8 like the Hummingbird and the OMAPs. But I find one thing weird:
This is a screenshot of an iPad having finished a Linpack benchmark. As you can see it's getting a score of more than 62 MFLOPS. iPhone 4's with a similar Apple A4 (albeit at a lower clock speed) are scoring around 36 MFLOPS, which I confirmed on a friend's iPhone 4 as well as internet sources. Now: the Apple A4 and Hummingbird are supposedly very related, and the biggest difference as I understand is actually the GPU, not the CPU core. So these large differences between an iPad and a Froyo Galaxy S should simply not be there.
To me, this can mean three things:
The Linpacks for iOS and Android are completely incomparable
Samsung and Texas Instruments CPUs can't take as much advantage of the JIT in Android as Snapdragons can
There is a large difference in MFLOPS performance between Snapdragons and Cortex A8's - Snapdragons would get a much higher score even when running iOS
To get a definitive answer about the Galaxy S's comparative MFLOPS performance, I think the best idea is to run a native (not using Android) benchmark on both a Hummingbird and Snapdragon (and maybe an OMAP). Could Ubuntu on a Nexus One and Galaxy S give us a definitive answer? Can anyone test?
This should be helpful for Motorola owners as well.
Click to expand...
Click to collapse
You can't really compare the iphone/ipad to android even though the hardware is similar. Android uses a VM so your score is highly dependent on the efficiency of the JIT. This is why you get a much higher linpack score when using 2.2 then 2.1. On a SGS you get around 7-8 MFLOPS with 2.1, and nearly double that 14 MFLOPS if you use 2.2 due to optimization of the JIT. While that's an impressive gain, 2.2 brought more optimization to the snapdragon line of CPU's. Mainly because they have 128 bit SIMD (compared to 64 bit on hummingbird) you get around a 4x increase in performance to around 40 MFLOPS. Someone will surely correct me but the 4x gain on the Snapdragon compared to the 2x gain on the hummingbird is basically because the Froyo JIT is able to send two 64 bit instructions at a time to the 128 bit SIMD in the snapdragon that is why there's a larger gap in linpack scores between the Snapdragon and Hummingbird CPU's in Froyo 2.2 compared to Eclair 2.1.
LeeBear said:
You can't really compare the iphone/ipad to android even though the hardware is similar. Android uses a VM so your score is highly dependent on the efficiency of the JIT. This is why you get a much higher linpack score when using 2.2 then 2.1. On a SGS you get around 7-8 MFLOPS with 2.1, and nearly double that 14 MFLOPS if you use 2.2 due to optimization of the JIT. While that's an impressive gain, 2.2 brought more optimization to the snapdragon line of CPU's. Mainly because they have 128 bit SIMD (compared to 64 bit on hummingbird) you get around a 4x increase in performance to around 40 MFLOPS. Someone will surely correct me but the 4x gain on the Snapdragon compared to the 2x gain on the hummingbird is basically because the Froyo JIT is able to send two 64 bit instructions at a time to the 128 bit SIMD in the snapdragon that is why there's a larger gap in linpack scores between the Snapdragon and Hummingbird CPU's in Froyo 2.2 compared to Eclair 2.1.
Click to expand...
Click to collapse
Scorpion can only issue one arithmetic instruction per cycle, be they 128-bit SIMD or 32/64-bit VFP (scalar). I doubt the JIT is capable of vectorizing data on-the-fly.
I'd attribute the increase FP performance to the fact that Scorpion's FPU is fully pipelined whereas the FPU of the A8 and A9 are not.
You're being excessive.
Because benchmarks mean nothing. Why does it matter? If your performance is good, why benchmark? It's just a placebo. Just go ahead and remove all of your benchmark tools. It's freeing.
Even though the HTC desire HD and Galaxy s have the processor with 1Ghz clock speed their linpack scores vary. SGS has about 12-14 and HTC Desire HD has 35-38. Also the same case with Nexus One. Can someone help me with this dilema?
vivekrk44 said:
Even though the HTC desire HD and Galaxy s have the processor with 1Ghz clock speed their linpack scores vary. SGS has about 12-14 and HTC Desire HD has 35-38. Also the same case with Nexus One. Can someone help me with this dilema?
Click to expand...
Click to collapse
Simple. Linpack is optimised for snapdragon processors. I'm sure if you searched you could have solved this by yourself.
Sent from my GT-I9000 using XDA App
And it's a synthetic benchmark anyway. Benchmarks are only useful if you know what exactly they are testing, they produce verbose outputs and if they test similar workloads to what you normally perform. Linpack is only somewhat useful if you only care about the speed floating point operations.
By the way, please stop saying it's optimised for snapdragon! To the best of what I've heard, that isn't the case. Snapdragons simply handle floating points better apparently. So yes, it might run better on snapdragon, but the developer probably didn't shift through the Dalvik code finding ways to speed it up on snapdragon.
We still don't really have enough information to understand if Snapdragon or hummingbird are faster in most applications, because we don't have an application similar to PCmark
Auzy said:
We still don't really have enough information to understand if Snapdragon or hummingbird are faster in most applications, because we don't have an application similar to PCmark
Click to expand...
Click to collapse
I know for a fact that in the "real world" the Desire HD $hits all over the SGS... I have both devices, and its very clear that the lag kills the SGS experience.
Its also worth noting, the Desire HD has the more optimised rev II Snapdragon processor. Clock for clock vs original Snapdragon, rev II is about 25% quicker...
PS - It is a shame tho, the Desire HD does not have native DIVX player support. You have to download Rockplayer for $10 to get that..
cheetah2k said:
I know for a fact that in the "real world" the Desire HD $hits all over the SGS... I have both devices, and its very clear that the lag kills the SGS experience.:
Click to expand...
Click to collapse
The lag is caused by the internal memory and file system though, not the Hummingbird.
cheetah2k said:
You have to download Rockplayer for $10 to get that..
Click to expand...
Click to collapse
eum. Rockplayer is free.
cheetah2k said:
I know for a fact that in the "real world" the Desire HD $hits all over the SGS... I have both devices, and its very clear that the lag kills the SGS experience.
Its also worth noting, the Desire HD has the more optimised rev II Snapdragon processor. Clock for clock vs original Snapdragon, rev II is about 25% quicker...
PS - It is a shame tho, the Desire HD does not have native DIVX player support. You have to download Rockplayer for $10 to get that..
Click to expand...
Click to collapse
How does the desire HD handle 3D games? When i went to the HTC event in London, it wasnt really very impressive when it came to the 3D games, the SGS was clearly superior thanks to its PowerVR 540 GPU.
cheetah2k said:
I know for a fact that in the "real world" the Desire HD $hits all over the SGS... I have both devices, and its very clear that the lag kills the SGS experience.
Its also worth noting, the Desire HD has the more optimised rev II Snapdragon processor. Clock for clock vs original Snapdragon, rev II is about 25% quicker...
PS - It is a shame tho, the Desire HD does not have native DIVX player support. You have to download Rockplayer for $10 to get that..
Click to expand...
Click to collapse
For starters, the question was based on linpack, but you are comparing the overall device. The software has already been shown to have a large impact on the devices. Furthermore, it's running bytecode, so it depends on the dalvik implementation.Your "facts" are actually non-conclusive, and seem to be based on observations.
Secondly, 25% faster isn't enough info when you don't know how hummingbird is in comparison. And even that is total crock, because 25% under which workload? It's like saying that a mechanical harddisk is half as fast as an SSD. However, under which conditions? We KNOW that mechanical HDD's operate horribly with random access. Well, what conditions have been improved on the scorpion CPU?
The harsh reality is, we don't know how exactly they compare, and benchmarks like Linpack or Quadrant only provide a tiny picture. It's more important to identify what kind of operations you need, and test those operations specifically. What we should ask is why you care about linpack?
I'm interested in finding out how the CPU's perform exactly though honestly (even against snapdragon).
What I've seen on quadrant is that it tests all aspects of a cpu. Arithmetic of int, short, long, xml parsing, audio and video decoding and the nexus one still has a better score only in cpu. Nexus one has about 4500 and my sgs has a max of 1992. Dosent this provide the big picture?
Sent from my GT-I9000 using XDA App
get CyanogenMod in SGS and try again
vivekrk44 said:
What I've seen on quadrant is that it tests all aspects of a cpu. Arithmetic of int, short, long, xml parsing, audio and video decoding and the nexus one still has a better score only in cpu. Nexus one has about 4500 and my sgs has a max of 1992. Dosent this provide the big picture?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
The big picture of what exactly? That quadrant doesn't give accurate results when comparing phones? This thread is a waste of time
There's been a topic about this before. To get a proper comparison of actual MFLOPS performance of both devices, we'd need to make a comparison that is not hampered by different versions of Android software, different Linux kernels or different levels of JIT optimization.
To properly compare them, you could load Ubuntu (same version) on both devices, and have them run a properly optimized version of native UNIX Linpack. That'd actually be testing the hardware capabilities. Native UNIX Linpack runs 62+ on the iPad's 1 GHz Apple A4 (of which the execution core is said to be identical to the Hummingbird) which is over four times as much as we're getting on Android Linpack on the Hummingbird.
I'd be happy to volunteer my Galaxy S, but we'd need someone with a Snapdragon phone to do the same.
vivekrk44 said:
What I've seen on quadrant is that it tests all aspects of a cpu. Arithmetic of int, short, long, xml parsing, audio and video decoding and the nexus one still has a better score only in cpu. Nexus one has about 4500 and my sgs has a max of 1992. Dosent this provide the big picture?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Nope.. Because as mentioned, it still goes through the VM, and you are looking at a weighted score or does it show every component individually? Also, when you say "all aspects of the CPU", how do you know it's all aspects. The fact you mention XML parsing as a proper test is silly, because it's basic string operations (array of numbers generally).
You also forget that Android is a timesharing OS, so background processes can have an effect. When I say the overall view, I mean a total breakdown of the CPU, cache, average cycles taken for specific instructions, etc.
You can't test the CPU with Dalvik, or even the NDK. And in the case of Linpack as mentioned, it's a very specific workload. There might be CPU specific workloads which hummingbird performs significantly faster than the other processors (we don't know). All that should matter to you, is how well your apps run.
As all the smart people have said, don't trust benchmarks and also Froyo's JIT compiler isn't yet optimized for hummingbird, That will change once google plays around with the nexus s.