If the Snapdragon came out about the same as the SGS2, then that seems to match what I said, and what I'd expect.
Edited my post to add that before reading this.
I'm not a fan of Nenamark as it seems to run, if I recall correctly, at the native resolution of the device rather than a forced resolution. This is great for a device specific benchmark, but it doesn't factor in proper fill-rate utilization. So, a device with a lower resolution will be given biased results against a device with a higher resolution. Case in point, the original Nenamark used to score the T-Mobile G1 higher than the Nexus One.
That's strictly true, but it's a part of why I like it (and hate it as you do).
If we're looking to benchmark just processor iron, fps-based tests fail when resolutions mismatch.
If we're looking to benchmark the entire phone, then from a gamer's perspective (the type that seems to care most about fps, personally, I don't), if they find some resolution acceptable to their eyes, then the fps benchmark is a true (read: reasonable) indication of their use case.
And therein is the benchmark dilemma that frustrates me - people consume benchmark results like horse racing results, when they mean very different things in very different contexts. Benchmarks can be aimed at compilers, iron, or end-user use cases.
Also, Nenamark is a GPU benchmark, not a dual-core benchmark. Most of the load will be on the GPU.
I must have worded that WAY poorly.
My intention was: Nenamark is a gpu benchmark, Nenamark 2 is designed for benchmarking dual cores because most of the new dual cores simply max out the original Nenamark and therefore indicate nothing. (If I am paraphrasing the Nenamark guys accurately enough.)
So, if I cared about bragging, I'd say I got 60 fps in Nenamark, but if I cared about being honest, I'd say I'd got 33 fps in Nenamark 2.
AnandTech - Samsung Galaxy S 2 (International) Review - The Best, Redefined
Using these tests, Anandtech forced a resolution of 720p. Because this is fill-rate intensive, and the Mali (SGS2) has superior fill-rate, it won all of the "game" tests. If they had scaled the resolution back to 800x480, the results would have been closer, probably moreso than your results.
Given that the Nexus Prime should have a 720p display, one would assume that the Mali is the GPU of choice here, but again, that atrociously low triangle performance alarms me.
Interesting, very (no sarcasm). I did not know about that one.
This also leads to another benchmark peeve I have:
what's the real test?
Graphic benchmarks typically make OpenGL calls and then the hipbone is connected to the legbone in software and silicone until something happens on the screen.
However - there's more than one way to skin a cat and in OpenGL, there are a vast multitude of ways to do the same thing and the final calls implemented for graphics in one game may be using completely different methods in others, even with screens that look much alike to end users.
So - using the most intensive or most efficient software methods sets boundary conditions for benchmarking the actual iron, and we users always want to buy the best iron - but that never means that having done so that our actual apps will _necessarily_ perform this way or that - it only suggests what the iron will do under ideal or (limited) stressful conditions.
According to Qualcomm's technical docs, I'm spot on. Because Snapdragon is asynchronous, you can view a dual-core CPU @ 1.5ghz as one big 3.0ghz CPU if needed. If an app requires relatively little CPU power (Angry Birds), you're not going to see that second core fire up, as shown in your post in that thread. Something more demanding, like a malware scan or encoding (Lookout app in that thread is a prime example) will try to max out both cores to finish the task in less time. The bottom line is that both cores are only used when needed, and when needed, it handles tasks in the order that I specified.
With native SMP, as A9 supports, the second core would fire up Angry birds at the speed it needs while the first core would handle existing system resources, or vice versa. The point would be to scale both cores evenly when possible to keep the speed low, and therefore, power consumption lower. So, the key difference here is that, due to SMP, both cores are typically used the majority of the time to automatically split tasks for the sake of efficiency. Snapdragon cannot do this, but S4 will.
I misread the paragraph before the one I'd approached out of context, and again, had edited my post before reading this as standing corrected.
However, on the point of SMP for load balancing for efficiency, that's true but again not the whole story.
The Snapdragon and Exynos processors feature asynchronous clock rates (each core can run at independent clock speeds), achieving asynchronous SMP (aka aSMP, and the HTC kernel is so marked for the user under About Phone), while the Tegra does not.
I would submit that aSMP offers significant performance improvements while saving power over a straight synchrous SMP layout, where load-balancing would fall to the kernel programmer to approximate correctly. That's a shortfall of the Tegra processsors to date.
So, to make your make your statement canonically correct, I'd suggest the predicate that an A9 implemented with asynchronous clocking is most efficient (as I don't think that's part of the A9 spec, or is it?).
~~~~~
For the non-chipheads:
It's important to note that the SMP (symmetric multiprocessing) approach in the operating system for multiple processor cores is unique to Android and is a blessing and a curse.
Because all our apps are running in a true preemptive multitasking way, apps have to share resources and services. That is the power of Android, and this allows our apps to be relatively small and not hog internal storage space.
But because apps are sharing resources (per timeslice) we can't let the apps hog anything, anywhere.
Enter the SMP approach - an effective way to get dual cores working and threaded apps (read: most all of our apps) working aok and running better on dual cores without needing to be re-written or re-compiled - it just works.
But - the SMP, while effective, is also primitive (like me).
iOS on the other hand, uses cooperative multitasking, so in a given timeslice, an app is getting all of the processor resources as those apps redundantly carry around their required services independently. This forces iPhones to have more memory because they need more memory.
But the approach is less primitive than SMP from strictly the app efficiency point of view, and between that and hardware acceleration, iPhones seem to run buttery smooth at sub-GHz clock rates.
My point: there's a charge that Android needs more processor capability to run at its best and that's true. But detractors claim that's because Android is bloated and not optimized, and that's entirely untrue.
It's simply optimized with other things in mind, and those things come at the price of needing more processing horsepower to really shine.
And with today's iron, we have that, and it's only getting better.
~~~~~
In my opinion.
