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 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.

> 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.

As part of a suite of benchmark programs, exactly.

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.

Nobody here has made any inappropriate conclusions from this data

Never said they did, I just said that useful conclusions can't be derived from the data.

so whatever are you arguing about?

DAB says it best:

In my architecture analysis days we used the term " Lies, damn lies and benchmarks!"

Most computer architectures are too varied to assess with simple benchmarks.  You really need to look at your proposed application and look into the system architecture to get a good feel about how well one processor will perform over another.

Unless you work with each processor in assembly language, you will seldom collect anything but interesting data.

True performance is always dependant upon the compiler, application structure, operating system, I/O drivers and many other details.

Raw power is seldom the only answer needed for a good system design.

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.

I wrote:

> Nobody here has made any inappropriate conclusions from this data

 

Gary Stewart wrote:

> Never said they did, I just said that useful conclusions can't be derived from the data.

Which coder27 disproved very specifically by making useful engineering conclusions from the data, and which I had also noted as being useful in my opening post by saying that the results were as expected.  Indeed, they are as expected, by any rational engineer with basic knowledge of architecture and types of ARM core.  You've now ignored these useful conclusions twice over in a hopeless attempt to salvage your completely empty and nonsensical set of posts.

If you dispute the data, go argue with those who captured it.  If you dispute that it is useful when applied sensibly in the way that we have applied it, that suggests lack of familiarity with basic CPU architecture.  In fact, you have not disputed anything at all, neither the data nor the reasoning, and you even agree with the cautioning about inappropriate use of benchmarks.

Yet somehow you still find a way to argue beligerantly here without denying the given data, without providing new data, without denying the given reasoning, without providing new reasoning, and in fact without contributing anything at all.  Your posts on this topic have significantly raised the bar on the concept of empty.

This thread was created to informatively and usefully summarize the simple benchmarking started in the RPF forum.  If you can't get your head around how this data can be interpreted usefully in the limited way that makes sense, fine, nobody is forcing you.  But please don't disrupt without clear reasoning an objective engineering thread in which data is considered valuable and in which the people present know how to use this data safely and sensibly.

Morgaine.

> 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?

> 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.