I have taken in all of the information being provided in this thread and have thought of a question I need to ask...maybe two.
When considering the post by Reddragon who states that, within a margin of 40%, performance is negligible between machines of similar caliber this comes to mind; the EVO 3D comes with Dual Core 1.2GHz CPUs. The Motorola Photon is supposed to come out with a Dual Core 1.0 GHz CPU. Is it possible then that the Photon could outperform the EVO 3d despite the small decrease in CPU muscle?
While I know this sometimes applied to computer processors, when we talk about Android processors, are there considerable differences in between manufactures where the T2 processor on the Photon is better than the 1.2 GHz in the EVO 3D from Snapdragon?
Someone posted earlier about not caring what the phone does now, but how it will fair in the future as software advances. Coming from someone who is an avid gamer in the PC world, I understand that the PC upgrades I buy today are already behind what will be for sale tomorrow. When I buy upgrade, or in this case a new phone, what I am really staving off is how long it will take for it to become obsolete.
I am battling to decide between the EVO 3D and Photon which is said to give the user the ability to remove bloatware.
Any thoughts?
Let's start with bloatware.
Sprint promised in June that they'd be allowing us to remove bloatware. On the Evo 3D, they didn't lie, they just didn't speak the whole truth. Some bloatware is removable, some is not without root (which we have). You'll need feedback on the Photon situation from Photon owners - I have the 3D.
On processor frequencies, the GHz of it all -
First, like modern desk/laptops, the processors in today's modern phones run at a variable speed - they run at just the speed required to make things work, and for normal tasks, that's a low clock speed.
Then, because this is after all a multitasking operating system, as tasks are added the processor is sped up to accommodate the additional load. This gives the user a very nice experience - as load from software increases, you don't see any lag (within processor and memory constraints, of course).
On processor design, the 2 cores of it all -
The first and largest difference between the Qualcomm 8660 in the 3D and the Tegra-2 in the Photon is that on the 8660, each core will run at independent clock frequencies and the OS support for that is called aSMP, or asynchronous symmetrical multiprocessing. The T2 runs both cores at the same speed, hence, SMP, symmetrical multiprocessing.
So - here's how that shakes out, and it's important to know to get to the real answer to your question.
Some apps can run in one core by design. Other apps, by their design, without a re-write, have things broken into "conceptually parallel" operations by the developer since before dual cores were around for Android. Such apps will have their parts (we call them threads) sent to each parallel core by the system automagically.
And because the two cores on the T2 are at the same frequency, the Photon kernel designers had to cleverly decide to make those decisions based on higher battery life (lower clock speed processing), higher performance (higher clock speed processing) or somewhere in between. It's quite similar to the performance balancing done for the 8660, but it's a little more work to do correctly sometimes. Anyway, both parties have succeeded.
Here's why you really care about understanding that and the real reason you really don't care about benchmarks -
Benchmarks, as touted by the blogs, try to make claims about phones and about processors and about all sorts of things - and that's 100% baloney sausage.
The benchmarks all run within the Android system and do not assess bare metal (CPU cores or graphics cores).
Here's what Android is - you take the Linux preemptive multitasking operating system (think: for what you care about, just like Windows 7 or OS X if you don't know Linux), add a clever kernel (the software that glues the other software to the actual hardware and softwares to each other) and some drivers to it, and then add a thing called the Dalvik Virtual Machine (VM) to that - that's Android.
Android apps are nice and small because they're tiny little things (compared to other systems) that run inside the Dalvik VM and call common services that are provided by the whole Android deal.
And those services don't amount to just one way of doing things - developers have a rich choice which calls to make for services and things we call APIs (entry points into Android's common software libraries).
And many of those choices do the same thing in different ways.
So - a benchmark is an app like any other.
It makes library calls that end up relying on services that end up relying on the kernel that ends up relying not just on the CPU or graphics cores alone but also all that other important silicon on the motherboard(s) of the phone.
If Benchmark A says Phone X is better than Phone Y - and you happen to be using apps where the developer used the same library methods used by Benchmark A, then your apps will run faster on Phone X.
If Benchmark A's library methods are not used by your apps, if your apps use alternative equivalent methods, then the Benchmark A will predict nothing about Phone X vs. Phone Y.
If Benchmark B says the opposite, that Phone Y is better, then the same two rules above apply.
There are no benchmarks that cover everything, nor will you ever know what sort of library methods are being used by your apps - and nor will you ever drop everything and run just one thing (the typical way to run benchmarks).
That's why benchmarks are useless to end users.
However - both application developers and hardware developers can use benchmark results to target their hardware or software stuff to specific uses and to map out future improvements.
~~~~~
Benchmarking your phone is a fun exercise and harmless exercise. It makes for good parlor tricks and drinking games.
I use a browser a lot, so I like browser benchmarks - I can tell from the benchmark and my experience in interpreting the result what I can expect because I can relate the benchmark to the app I use.
Linpack, for example, may still be carrying within it some of the mainframe benchmarking code I wrote decades ago (or it may not, I've not been motivated to check and it's not like it was _mine goodie_ it was like _community please share_). If so that it does still carry those legacies in code, I can tell you for a fact that that was never designed to be used in this sort of operating system environment to tell you anything.
But it gives a fun number to compare and discuss.
~~~~~~TL/DR version:
Bottom line is try each phone and consider which features are best for you, and go for it as a happy camper.
People will try to convince you that among the top processors, it's all like Ferrari vs. a couple of Ford Pintos, when in reality, it's like comparing Audi vs. BWM vs. Mercedes - the silicon is all top-notch stuff and it's all busy doing all that stuff making the operating system happen and the phone as a phone happen.
So, choose on features and trust your gut instincts because they're both top choices and you can't go wrong.
Hope that helps!
PS - the only real use for benchmarks I've found: when upgrading versions of Android on MY phone, they can give a slight preview of what performance improvements I might expect. When I remember to check them, which, I often don't bother.
