dualcore processor
- Thread starter thebizz
- Start date
There's a little bit more to this than can easily be described in a tweet or even half thought out forum post.
It's sort of a rule in microprocessor design (particularly CMOS) that if you have your choice between 2x clock and one adder (for example) or 1x clock and two adders, perhaps dispatching adds to alternate adders every other clock cycle, it's better to take the two adders at the lower clock. This is in part because the higher clock might require a higher voltage and power can increase by the square of the voltage, though power increases linearly by frequency.
This is a little too fine grained when replicating entire cores but there is still something to it - if you can have two 800 MHz cores at lower voltages than a single 1600 MHz core, *AND* the task you are executing is perfectly parallelizable, the two 800 MHz cores will perform at "exactly" the same speed as the single 1600 MHz core and use less power while doing it.
The problem is that nearly nothing is actually perfectly parallelizeable, but in balance to that modern microprocessors have such fine grained power control that the entire unused core is likely to be shut of when not in use - with microsecond scale restart time - so there's not actually a power impact of having the second core there if it happens to not be doing anything.
A previous commenter made note that many applications are probably already multithreaded and thus would "automatically" make use of multiple cores if available, presuming that the operating system scheduler was aware of those cores and scheduled both of them. This is partly true - the driver for the GPU is going to be running in a different thread, a lot of the UI will probably be running in a different thread, but it's partly untrue as well. When you launch a single application that is computationally intensive, unless the programmer has designed for parallelism, the core workload is unlikely to get any advantage from the two cores and the only increase in performance is going to come from the incidental use of other threads for UI or GPU, and that's only going to be a few percent in most cases. The bulk of time is going to be spent in a non-parallel sequential loop. So in this particular case a single 1600 MHz core would be a much better choice than dual 800 MHz cores and moreover a more complex (wider-issue) 1600 MHz core would be far, far better than two narrow-issue 800 MHz cores, at probably less logic gate/transistor count and the more complex processor has the advantage of turning off parts of itself and downclocking/undervolting itself when more or less idle.
There is no simple description of the relative performance and power use of two cores vs one core at a higher clock or what the advantage or disadvantage might be. It is very simplistic to say that two cores would be doing half the work in the same amount of time and while listening to the podcast I was never actually clear as to what the hosts were trying to say.
The number of gates switching to perform a task across two cores is going to be (around) twice as high as with just one core (though there may be common features - a single bus interface unit, ram controller, etc), but as I said voltage is likely to be higher with the one core, frequency 2x (to keep the comparison even) and thus power consumption likely to be higher.
There's another problem that I used to run into, is software validation. Software that would work perfectly fine even when multithreaded on a single core would break if not designed just right when running on multicores.
That aside, there really isn't much of a reason to avoid dual core (or more) CPUs if they are available. The tradeoff really isn't going to be 2x800 MHz or 1x1600 MHz - it's more like 2x1600 MHz or 1x1600 MHz and that makes the decision making process much more simple. Of course the 2x cores will consume about 2x the power of the 1x core but you also have the option of simply turning off one of the cores if power or thermal considerations become an issue (moment by moment in real time).
Android *should* be smart enough to recognize when it is running an application which was specifically designed for multiple cores (eg if a single process has created a bunch of threads it's likely to be designed for multiple cores) and when one of those kinds of applications is in the foreground, turn on the second core and/or start scheduling to it.
Then you get all the advantages of sticking with a single core (power) and the potential performance improvement of hopefully >50% with the availability of the second core, when something can make use of it.
From the end user perspective, I imagine the display backlight is going to be using more power in the normal case than the CPU anyway. You're not really going to see a increase in battery life by having multiple cores available, or at least not a very noticeable one.
So that was a pretty rambling post and there's no simple way to really describe the advantages and disadvantages, but the overly simplistic description of advantage and disadvantage that was sort of floating around up until now wasn't really contributing any information to the topic.
This is the thing I keep reminding myself whenever there's a promise of better battery life from a more efficient processor. The screen is such a huge draw on the battery that the proc may not even have a noticeable difference in comparison.
What the world really needs, though, is better battery technology.
Agreed. We can only optimize battery performance so far before you just simply need batteries with higher capacities in smaller real-estate. We're heading in that direction, but it just seems like it's taking forever. 1500 mAh seems to be the standard at this point, I can remember when that was practically unheard of. At least not in compact form.
@valeuche Thanks for the accurate and detailed information. I still think there will be some improvement as background and UI tasks get scheduled to the second core. Not to mention that things that the browser would undoubtedly be re-written to support both cores which should make web browsing faster and less battery intensive. Something that almost all of us will be able to appreciate.
All that said, the ViewSonic G-Tablet, even without full SMP (dual-core) support is *extremely* fast and responsive. I've got an Evo and it's nice, but the sheer instantaniousness (yes, I made up a word) of the G-Tablet has really blown me away.
I can also verify that the battery on this thing is a beast. For example, I fully charged my G-Tab last Saturday afternoon. Played on it for about 2 hours Sat, and about 1 hour each day after that. All the rest of the time it was "asleep" and doing email/twitter/facebook updates every 15 minutes. When I finally plugged it in again to charge the following Wednesday, I had about 35% battery remaining. It went ~96 hours, with about 5-6 hours of that being active use (and several of those hours being games), and used less than 75% of the battery.
That's pretty darned good in my book
I'm running the VEGAn ROM, BTW. It's much faster and more stable than TNT Lite from my experience.
All that said, the ViewSonic G-Tablet, even without full SMP (dual-core) support is *extremely* fast and responsive. I've got an Evo and it's nice, but the sheer instantaniousness (yes, I made up a word) of the G-Tablet has really blown me away.
I can also verify that the battery on this thing is a beast. For example, I fully charged my G-Tab last Saturday afternoon. Played on it for about 2 hours Sat, and about 1 hour each day after that. All the rest of the time it was "asleep" and doing email/twitter/facebook updates every 15 minutes. When I finally plugged it in again to charge the following Wednesday, I had about 35% battery remaining. It went ~96 hours, with about 5-6 hours of that being active use (and several of those hours being games), and used less than 75% of the battery.
That's pretty darned good in my book
I'm running the VEGAn ROM, BTW. It's much faster and more stable than TNT Lite from my experience.
Last edited:
Similar threads
Facebook
Twitter
Instagram