SBC CPU Throughput

Reading that thread is depressing. The general lack of comprehension of cpu speed governors - yep, it's doing nothing, so slow down the clock turn things off etc to save power. That's why it shows 300 bogomips, nowt to do with what connector you supply power through.

Would we really like our smart phones battery to last 5 mins instead of (maybe) a day ?  Or is this technology a good thing ?  

(I prefer the phones battery to last a week, no smartphone for me!)

Anyway, I claim victory on the benchmark

I'm sure it'd be faster if it'd run long enough to bring the processor out of idle and off the slowest clock speed too.

On a more serious note, it's about 12.8 secs on a sabre-lite with debian armhf, so the BBB angstrom build seems to have been better optimised than the generic debian.

On the BBB with angstrom I get 12.090 with the ondemand governor and 11.86 with the performance governor, showing that the governor has some latency, but nothing that anyone will care about.

Bogomips on the A9 core of the sabre-lite is 1988 per core vs 990 on the BBB's A8 showing the futility of artificial benchmarks.

I did my share of chuckling at some of the beginners' posts there too while looking for usable numbers, but I think the interaction with CPU speed governers eventually dawned even on the beginners in the thread (well aided by people like dom), so it occurred to me while browsing that the discussion there was having a useful educational effect.

They were even advising caution about assigning inappropriate meaning to BogoMips.  Win! \o/

PS. I added your Sabre-lite and BBB findings to the table as additional datapoints.

PPS. Cortex-A8 looks set to having a long life, despite many newcomers buzzing around its heels.  It's also the ARM core in my original Samsung Galaxy Tab 7" tablet, and has no trouble being snappy enough for that application.

I wrote:

> Data is always good, and sharing it is also good

 

Gary Stewart wrote:

> Only if it is good data. This is so obvious it almost hurts to have to write it.

I have no reason to believe that any of this data is bad data.  You have not pointed to any datum in the list and suggested that it is bad, nor have you given any reasons why we should believe that one or more of the numbers captured are erroneous.  It sounds like you're raising FUD just on general principles, as you seem prone to do in this forum.  In any event, if you disbelieve any of the data that the members of the RPF forum have released, take it up with them first.

The only data in the table provided by members of this E14 forum is selsinork's.  If you believe that any of his data is bad, please take it up with him first, and give solid engineering reasons because he's not likely to take any nonsense from you.  Bad data is bad data and I dislike it as much as anybody, but all indications are that all these numbers are genuine and accurate.  Unless we have evidence to the contrary, this is entirely good data.

The interpretation that people give to good data is an entirely different matter, and my cautions were the usual advice about taking perfectly good numbers and making wholly incorrect conclusions about them.  Even you have agreed with that, so you're really just looking for a fight as usual.

There is absolutely nothing at all to argue about here, we all agree about the merits or otherwise of benchmarks.  AFAWK the numbers are totally accurate.  Use them appropriately and they can be useful, but use them incorrectly to tell you how real-world applications will perform and you may well conclude something erroneous.  News at 11 !!!

 * morgaine sighs

The interpretation that people give to good data is an entirely different matter, and my cautions were the usual advice about taking perfectly good numbers and making wholly incorrect conclusions about them.

How can you provide a useful interpretation of data that in your own words you should "take (benchmarks) with a truckload of salt, and evaluate with a suitable mixture of suspicion, snoring, and mirth.". I mean really,

if this is your idea of normal cautions for data I'd like to see your idea a real bona-fide warning.

AFAWK the numbers are totally accurate.

But not really useful for the real world (see previous responses) which is the point you keep dancing around.

Even you have agreed with that,

I agree with what you said, but not that the data in this "benchmark" is good in the sense that a useful interpretation of much of anything is possible using it. Which is

again the point you keep dancing around. It is far too simplistic a benchmark to provide that.

so you're really just looking for a fight as usual.

Something I've seen you do on numerous occasions yourself.

> As to the benchmark itself, no single line program line can be considered as a valuable synthetic benchmark of anything.

...

> I was totally unaware that triviality in any form was considered a good trait for a benchmark. Doesn't make sense to me though.

...

> It is far too simplistic a benchmark to provide that.

You obviously have no clue what this benchmark does.  It isn't a "single line program" at all.

Invoking the program takes a single line, and that is a good thing.

There's a very important difference between the command to invoke a program

and the program itself. 

Gary Stewart wrote:

 

How can you provide a useful interpretation of data that in your own words you should "take (benchmarks) with a truckload of salt, and evaluate with a suitable mixture of suspicion, snoring, and mirth.".

A rational person can provide a useful interpretation by using ordinary engineering knowledge and commonsense.

I refer you to coder27's post about the data confirming that execution times are proportional to clock rates for a given architecture, and likewise confirming that there is a significant improvement from ARM11 to Cortex-A8 for a given clock rate.  These are helpful observations in that they confirm what is expected, and if the numbers had indicated something entirely different then we would have some very serious issues to investigate.

> I wrote:
> AFAWK the numbers are totally accurate.

 

But not really useful for the real world (see previous responses) which is the point you keep dancing around.

See previous section.  It is you who chose to dance around and ignore the useful and helpful interpretations of this data explained well in coder27's post, and instead dived in here directly at me without provocation nor valid reason.

I have consistently stated that good data is useful when used appropriately, but unhelpful when used inappropriately.  I clearly said "Results roughly as expected" in my opening post which points to the data being useful, and then I gave the usual cautions about using benchmark data wrongly to reach inappropriate conclusions.

Nobody here has made any inappropriate conclusions from this data, so whatever are you arguing about?

Morgaine.

As far as I know, some open source* and possibly some commercial benchmarks do a similar computation as part of a CPU intensiveness test (at least for single cored processors). Probably, for an embedded app where we may not be interested in say, file I/O, or multimedia extensions or multi-cored results, then it does have some value.

*Source: OSmark

Yes actually I do know that it runs as an interpreted program in the bash shell and executes echo to send a math equation to execute and executes the external compiled program (bc) to compute pi to 2000 digits

and time and how long it takes to do so. So you are mainly testing floating point performance. While this is not really simplistic (not really complicated either), it is not a really useful for much of anything other

than a FP benchmark either.

floating point doesn't get you 2000 digits.

Run the program and count the digits yourself. It is a well know exercise to compute pi to way more digits that are available on any processor architecture

that I am aware of. I think the record is quite a few more than 2000 now (10^13 according to wikipedia).

>I think the record is quite a few more than 2000 now (10^13 according to wikipedia).

floating point doesn't get you 10^13 digits either.

So how do they do it ?

Perhaps you have heard of arbitrary precision arithmetic ? It is available in integer and floating point libraries for

several languages and allows higher precisions than are directly supported by the native hardware and use the

native hardware to do it.

I don't believe that's how they calculate pi to so many digits (very clever algorithms I suspect, not my area of expertise)

but I'm pretty sure they do use floating point since it is normally done on a supercomputer.

So how do they do it ?

Perhaps you have heard of arbitrary precision arithmetic ? It is available in integer and floating point libraries for

several languages and allows higher precisions than are directly supported by the native hardware and use the

native hardware to do it.

I don't believe that's how they calculate pi to so many digits (very clever algorithms I suspect, not my area of expertise)

but I'm pretty sure they do use floating point since it is normally done on a supercomputer.

> Perhaps you have heard of arbitrary precision arithmetic ? It is available in integer and floating point libraries

no, I've never heard of an arbitrary precision arithmetic library that uses floating point.

Perhaps you can show an example.

http://www.hvks.com/Numerical/arbitrary_precision.html

http://www.apfloat.org/apfloat/

http://gmplib.org/

There are more, and you can find them using google.

I was looking for ones that are implemented using floating-point.

All the ones I'm aware of use integers, as described in Knuth's Volume 2.

http://www.nongnu.org/hpalib/

"The functions forming the HPA library are all implemented in a portable fashion in the C language. The IEEE 754 standard for floating point hardware and software is assumed in the PC/Unix version of this library."

There are also several papers (pdfs) from that describe using IEEE 754 floating point hardware for arbitrary precision arithmetic.

> The functions forming the HPA library are all implemented in a portable fashion in the C language.

I have looked at this C code, and it sure looks to me like it is doing everything using integers.

For example, xadd.c contains the code to add two numbers, and it declares these variables:

     unsigned short pe[XDIM + 1], h, u;  

     register unsigned short *pa, *pb, *pc, *pf = pe;  

     register unsigned int n = 0;  

     short e;  

     register short k;

all of which are integers. 

The arbitrary precision numbers are stored in a struct called xpr,

declared in xpre.h, defined as:

  struct xpr  

  {    

     unsigned short nmm[XDIM + 1];  

  };

which is clearly declaring an array of integers.

Where are you seeing the floating-point operations in this library?

I didn't have time to check the C code so I searched the main page for references to hardware and then the documentation page looking for the use of float

or double in declarations of functions that were not conversions from one of those two formats to the extended precision format and I found several of those.

I also searched for a description of the xpr structure on the document page to see if it was using integers but could not find one. I should have looked at the

code to be sure. While writing this I found a description of the extended numbers format used in the xpr structure on the document page that I somehow

missed the first time which confirms that it uses integers.

I also checked out bc more carefully. I have never used it in any of the shell scripts that I've written so far but every reference on shell programming I've read says

to use it if you need floating point numbers in a shell script. What I found was that it uses a selectable precision fixed point decimal digit format for its arithmetic

operations that it allows you to select an arbitrary number of digits on both sides of the decimal point. So no floating point here either.