SBC CPU Throughput

selsinork wrote:

 

Anyway, having persuaded the angstrom binary to run on debian on the sabre-lite, it runs in 9.7s vs 12.8 for the debian native version.

I added your new data point to the table.

This is really cool, I think it might lead to some interesting analysis and end up improving our understanding of the figures.

coder27 wrote:

 

I think Debian is compiled for ARMv4.  Angstrom might be compiled for ARMv7,

which may account for the difference.  Angstrom might also be compiled with a

later version of GCC than Debian.  I'm pretty sure the vector floating point (vfp)

and neon are not relevant factors.

 

Edited to add:  Looking again at your table, I see Debian listed as ARMHF,

which rules out ARMv4, so maybe that isn't the difference.

The debian gcc was built with these options

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard

gcc version 4.7.2 (Debian 4.7.2-4)

the angstrom one is slightly newer and is a Linaro build gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01)

however it was cross compiled and the particular arch settings don't appear in the output of gcc -v

Since both the BBB and Sabre-Lite are armv7 it seems that it'll be possible to get the same rootfs to run on either, so I should be able to put the debian armhf that I have on the SL onto the BBB and the BBB's angstrom onto the SL.

I'll give it a try and let you know how I get on

selsinork wrote:

 

I'm still trying to get to the bottom of the difference between debian & angstrom on the same hardware

Any chance they're using different amounts of L2 cache?  From a quick read, it looks like the Sabre-Lite has 1MB L2 cache which the application should easily fit into, but maybe Ångström only allocates 256KB?

General principle: benchmarks that fit into on-chip cache don't test external memory performance

Well yes, cache can be a factor.  IME usually about the only thing you can do with cache is turn it on or off, beyond that the cache architecture will govern what gets used and how.

According to the datasheet the AM3359 only has 256KB, so as you say if it fits in that then it should fit in the iMX6's 1Mb. However, we're talking A8 vs A9 and from different implementers. Chances of the cache architecture being somehow different are good.

So yes, maybe it's simply a case of debian being built with every possible knob turned on and therefore suffering from bloat and excessive cache misses.

Angstrom being the roadrunner to debian's coyote

Now all we need is to get Acme Corporation to start building BBB and all our problems will be solved

selsinork wrote:

 

Well yes, cache can be a factor.  IME usually about the only thing you can do with cache is turn it on or off, beyond that the cache architecture will govern what gets used and how.

Turning off the on-chip cache would eliminate that variable from any tests that want to measure external memory throughput.  If it's not feasible during normal running, it might still be possible as a kernel boot option, which would be good enough for testing even if not all that convenient.  I haven't come across such a kernel option yet, but it wouldn't surprise me if it were available among the CPU options.

Inevitably turning off the cache will be architecture-dependent, although that's not really an obstacle when the entire point is to make a device-dependent measurement,  A quick web search shows that 32-bit Intel CPUs allow you to turn cache off by setting bit 30 of control register cr0.  People have done this by loading a kernel module to do the operation, apparently with success judging by the large slowdown.

It doesn't directly address our interest though, which is to measure cached throughput identically on two different devices which may have different cache sizes and may not be caching a given measurement program in the same way.  That's substantially harder.

minnowboard,  Intel(R) Atom(TM) CPU E640   @ 1.00GHz, production-Angstrom-development-GNOME-image-eglibc-ipk-v2012.12-minnow-2013.07.10.img

bc-1.06.95 compiled from source on the minnowboard itself as the version of bc included with angstrom segfaults whenever the -l mathlibrary switch is used.

21 seconds

selsinork wrote:

 

21 seconds

That's interesting, as an initial data point for Atom E640 here.  Probably no surprise given the results of various review sites when comparing Atom (not sure which SoC) versus Cortex-A15 in tablets and chromebooks.

It's just the start of the inquiry though, and I bet the numbers will vary a lot as the platform libraries and optimizations change.  I'd like to see what the Minnowboard forums have to say about it too.  It's still very early days.  More specifically, I'd like to hear whether this initial measurement seems reasonable to them given the instruction set, clock speed, and memory + cache performance.

I'll pop it into the table, but let me know if you decide it wasn't actually representative and needs changing.

I think it's going to be reasonable, as a comparison a different system with an Atom 230 @ 1.6Ghz does it in about 14 seconds in 32 bit mode.

However, historically Atom processors were better in 64 bit mode and the same system with the same version of bc, manages it in 9.3 seconds in 64 bit mode.

Pity then that the E640 is apparently 32 bit only.  Interestingly, when looking at /proc/cpuinfo on the minnow it includes 'lm' which would suggest 64 bit may be possible and I'll try that out at some point too.

Regardless, it seems clear that for this particular benchmark the Minnowboard doesn't do well against it's competition and would seem unlikely to be competitive even in 64 bit mode.

So price/performance comparisons are a legitimate target along with performance per watt, is there really a killer feature that makes the minnowboard worth it ?   I'm not so sure..

You don't have permission to edit metadata of this video.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: SBC CPU Throughput Comment on DSP  Vs.  CORTEX-M4 with dsp & fpu

Poster

Upload Preview

Ok

Cancel

Simple test running on top of processor with no kernel (C compiled with IAR ARM 6.40 )

selsinork wrote:

 

So price/performance comparisons are a legitimate target along with performance per watt, is there really a killer feature that makes the minnowboard worth it ?   I'm not so sure..

I/O bandwidth perhaps?  With SATA and gigabit Ethernet, it seems likely that Minnowboard would perform well in I/O-limited applications like NAS and also in web services, as long as the web service is not a CPU-intensive one.

Measurements of network, USB, [u]SD, SATA and PCIe latencies and throughputs could be useful when matching boards to applications.