SBC CPU Throughput

Olimex A20-OLinuXino-MICRO  Debian 7.0 from the downloadable sdcard image on their website.

912MHz A20, 3.4.67+, 15.850s

A10-OLinuXino-LIME, Debian 7.0 from the LIME downloadable image

1000MHz A10, 3.4.67+, 13.927s

I'm guessing that from previous results that either the angstrom version of bc, or my self compiled one will improve these somewhat. (I have some re-compiling to do before I can test that theory)

SATA throughput on both is >100MB/s or as fast as my test drive can provide..

Olimex A20-OLinuXino-MICRO  Debian 7.0 from the downloadable sdcard image on their website.

912MHz A20, 3.4.67+, 15.850s

A10-OLinuXino-LIME, Debian 7.0 from the LIME downloadable image

1000MHz A10, 3.4.67+, 13.927s

I'm guessing that from previous results that either the angstrom version of bc, or my self compiled one will improve these somewhat. (I have some re-compiling to do before I can test that theory)

SATA throughput on both is >100MB/s or as fast as my test drive can provide..

Great, thanks for those measurements, both added to table!

I notice that the Cortex-A7 seems to be slower than Cortex-A8 on this benchmark generally, after normalizing the figures to account for varying clock speeds and Angstrom bc binaries.  Is this something for which we have a solid explanation yet, or do we need to start theorizing?

Morgaine.

Nice little graphic of ARM family evolution:

It doesn't seem to normalize for core counts though, but shows the aggregate throughput of all cores on a SoC together --- good for marketting but not as clear for our purposes.

Morgaine.

The A7 is basically a tweaked A8, the idea being that it's feature compatible with A15 but much lower power. To achieve that, it's still an in-order architecture, but they made some compromises in order to keep the power consumption low while making the core more easily synthesizable.  Remember, the goal of the A7 is more about being the low power part of a big.little SoC with an A15 - the target being a background task processor for something like a smartphone where you don't need a power hungry core eating your battery when you're not actively using it.

There's an interesting discussion here http://www.anandtech.com/show/4991/arms-cortex-a7-bringing-cheaper-dualcore-more-power-efficient-highend-devices

I'm not normally a reader of annandtech, and you'll need to ignore the fanboys from both sides in the comments, but there's a reasonable explanation of some of the reasons A7 is slower in some areas than A8.

Morgaine Dinova wrote:

 

It doesn't seem to normalize for core counts though, but shows the aggregate throughput of all cores on a SoC together --- good for marketting but not as clear for our purposes.

Yep, definately a marketing slide. Performance of the A15 graphed against power consumption of the A7 certainly makes it look good. Once you make the jump from fairly simple in-order execution to complex out-of-order there's a penalty in the form of increased power. Intel discovered that in the Prescott days and dropped back to a simpler architecture starting with Core.

While Arm is ahead on power consumption, that's at the cost of performance. As they start aiming for increased performance and x86 territory, the power consumption will have to increase as well. That's not to say they can't get similar performance with lower power than Intel can today, but who knows what Intel will be doing by then.

That said, I'm finding the A9 powered i.MX6 to be far more performant than I'd expected. Perhaps having my first proper interaction with Arm being the ARM11 based RPi has left me with expectations that are too low.

selsinork wrote:

Morgaine Dinova wrote:

 

It doesn't seem to normalize for core counts though, but shows the aggregate throughput of all cores on a SoC together --- good for marketing but not as clear for our purposes.

Yep, definitely a marketing slide. Performance of the A15 graphed against power consumption of the A7 certainly makes it look good. Once you make the jump from fairly simple in-order execution to complex out-of-order there's a penalty in the form of increased power. Intel discovered that in the Prescott days and dropped back to a simpler architecture starting with Core.

 

While Arm is ahead on power consumption, that's at the cost of performance. As they start aiming for increased performance and x86 territory, the power consumption will have to increase as well. That's not to say they can't get similar performance with lower power than Intel can today, but who knows what Intel will be doing by then.

Yes, that's a very pretty slide Morgaine posted.  But we know we have to be careful with the term "peak performance", which a clever wag once defined as "a guarantee from the manufacturer that you can't go faster than this".

Speaking of clever aphorisms, you may have heard Hamming's quote: "The purpose of computation is insight, not numbers".  Gio Wiederhold transformed this into: "The number of computations without purpose is out of sight."  Well, that's what you get with out-of-order speculative execution: you know a bunch of results will get discarded and the power expended to compute them will be wasted.  Whenever I see an implementation with long pipelines I think about all those flushes and all those electrons rushing from ground to Vdd acting like a big switched-capacitor resistor.  And for what purpose?  So that wasteful software has acceptable performance (sigh).

John Beetem wrote:

 

Well, that's what you get with out-of-order speculative execution: you know a bunch of results will get discarded and the power expended to compute them will be wasted.  Whenever I see an implementation with long pipelines I think about all those flushes and all those electrons rushing from ground to Vdd acting like a big switched-capacitor resistor.  And for what purpose?  So that wasteful software has acceptable performance (sigh).

So true.  And software is often wasteful even in places where we don't usually expect it, simply because you can't normally satisfy a wide range of requirements at the same time equally well.  Here's an example.

Desktop machines already surpassed (a few years ago) the power they need to implement the desktop metaphor perfectly in respect of performance, meaning that normal "metaphoric paper" operations such as organizing documents and folders are perceptually instantaneous.  (More power is needed only by algorithmic operations such as searching, which typically aren't yet perceptually instantaneous.)

And yet, the dumb software merrily runs the CPUs turned up to 11 in order to respond in 100 microseconds instead of in the few milliseconds required by frame rate and our perceptions.  It's a waste of power because the efficiency/clock-rate curve is not linear (it's less efficient at higher speeds), and the time saved by doing something faster can't be turned into energy saving by idling sooner because switching to idle is not an instantaneous operation.  The combination of these two factors means that the fast CPUs of the last several years waste energy for the bulk of what we do on the desktop.

Morgaine.