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.

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

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.

The only thing I have trouble wrapping my head around is why stating the obvious is a considered a useful engineering conclusion.

Which coder27 disproved very specifically by making useful engineering conclusions from the data,

coder 27:

They confirm that when the clock rate increases from 700MHz to 1GHz on

the same architecture, that the benchmark timings have a corresponding

improvement.

Fairly sure this has been well known since the dawn of of non one of a kind computers and doesn't really need confirmation.

They confirm that when the architecture improves from ARMv6 to the superscalar ARMv7, but the clock rate is held constant,

there is acorresponding improvement.

Again well known since the ARMv7 has been out for quite a while now. I guess it doesn't hurt to confirm it one more time.

They confirm that when both the architecture and clock rate are both held constant, such as between the cubieboard and BBB, that the

benchmark timings are relatively constant.

Again simply stating the obvious. At least it disproves the negative right ?

They confirm that between the RPi and BBB there is a substantial performance difference, for integer compute bound, much greater than

the difference in price.

As long as this narrowly defined benchmark is the only performance difference that is important to you, great. One simple benchmark

and done.

Back to you:

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.

No, I have been around almost all of the microprocessor based CPU architectures (and a couple that used discrete TTL and real magnetic core memory

as well) since before the Z80, so there's no lack of familiarity there.

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.

Never disputed the accuracy data, I did dispute the reasoning used to "prove" that it provided much in the way of useful engineering information with a

reason in every reply to you. Of course I agree with cautioning about the inappropriate use of a benchmark (different from benchmarks as only one

benchmark was run here and that one of the reasons I used that you "lost") but yours went well beyond any semblance of an appropriate caution

and showed a distinct lack of faith in the usefulness of the benchmark data (not the data itself) which is exactly what I said.

Yet somehow you still find a way to argue beligerantly here without denying the given data

Never questioned the accuracy of the data just the usefulness of the interpretation of a single narrowly focused benchmark so why do you keep bringing

that up ?

without denying the given reasoning, without providing new reasoning

I have provided both in my posts and have done so again in this one. That you continue to "miss" it is hardly surprising. You have a knack for

never responding to any "given" or "new" reasoning at all or with anything other than repeating what you said before in effect doing exactly

what you say I am doing. Or just accusing someone of not using reasoning at all or at least your interpretation of it again exactly as you

have done here.

Your posts on this topic have significantly raised the bar on the concept of empty.

An area you have also ventured into yourself on occasion including this very thread. And several personal attacks from you to boot !

I thought you didn't approve of such things. Well again, not surprising.

This thread was created to informatively and usefully summarize the simple benchmarking started in the RPF forum

And the simplicity of this single benchmark and the fact that it is a single benchmark have been the center of the reasoning about the usefulness

of its data since the beginning. Any conclusions about the performance of a complex system based on one simple test is more likely to misinform

than inform, or at best just prove what you already know. I guess that can be considered useful to some.

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.

If you can't get your head around what is actually useful fine nobody is forcing you.

But please don't disrupt without clear reasoning an objective engineering thread

Sorry, I don't consider you to be the final arbitrator on what clear reasoning or objective engineering is although I know you have

projected yourself as such several times in the past often rejecting clear reasoning and objective engineering when doing so.

in which data is considered valuable and in which the people present know how to use this data safely and sensibly.

Yes it is valuable, the more data (from benchmarks, note the plural) the better, especially when you need to use it sensibly.

I'm not sure were using benchmark data safely comes from and you forgot responsibly.

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.

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.