Lpc2000

At 03:22 PM 2/27/05 +0000, tsvetanusunov wrote:
> > An accurate indisputable benchmark I've found generally covers too narrow
> > an area to have a general use. For example pin toggling can be made a
> > fairly bulletproof benchmark but really doesn't matter unless you have a
> > particular need to toggle a pin quickly.
>
>this is one of our application, we are developing USB-JTAG for ARMs
>and toggling GPIO ports is quite important for this application, so
>AT91SAM7Sxx with build in USB and toggling twice faster GPIO ports is
>definitely winner for this kind of application

That raises a question, I haven't seen answered.  How does the pin toggling 
speed compare between an LPC running at full speed (60 MHz, no slowdown on 
the peripheral bus) and an SAM part at it's equivalent full speed?  The 
only comparisons I've seen refer to pin toggling efficiency rather than 
maximum rate.

> > A benchmark that purports to be generally useful generally is not accurate
> > and indisputable.  The classic whetstone and dhrystone benchmarks have 
> been
> > the subject of endless disputes (and IIRC compiler tweaking).
>
>I understand this, but I like what Richard @ FreeRTOS did:
>
>- test setup
>- 16bit math
>- 32bit math
>- floating math
>- bubble sort
>- data block memory move
>- conditional branching
>
>(let me know what elese we are missing here)
>
>these are the basic codes used in any application, so benchmarking
>them at different ARMs may be useful when you choose device for your
>future application
>and of course none of above can be considered as biased toward some
>compiler ot other, they will just show how good the compilers handle
>them

Biases will be there regardless.  They will be there in the underlying 
assumptions made about how the code should be structured.  In what compiler 
options should be picked etc...  If they use the same general purpose code 
for all combinations of compiler/micro than they are biased by not using 
the combination to it's best effect.  If they use combination specific 
optimizations they are biased by not comparing identical cases.

In the case of the various ARM micros, whether the micro was optimized to 
run thumb or standard code could have a significant effect on the outcome.

> > As a sage once said the only benchmark with any meaning is the application
> > you are going to run.
>
>completely agree, but if you see xx% improvement in your data memory
>move for instance on LPC (with 32 bit external data bus) toward OKI
>(with 16 bit external data bus) this will mean something when you
>decide which one to use in your time critical project who does
>transfer large amounts of memory blocks to the external memory right?

Perhaps.  It would depend on how closely the memory activity in the 
benchmark matched that in the application.  And whether it used optimized 
assembler or standard library code or a simple C routine or.....

If your application spent 50% of it's time in moving blocks of memory (or 
maybe only 1% but in a time critical portion) for instance it would make 
sense to use hand optimized assembly (and whatever hardware assists the 
micro might have).  In that case the benchmark could be rather specific to 
each micro.  A micro with a DMA peripheral might be better suited to the 
task even if a simple loop measurement on it was significantly slower than 
it's competitors.

>we'll release the codes on our web together with the benchmarking so
>everyone will be able to re-produce these tests, we are just currious
>and don't want to prove that one ARM is better than other

Before spending too much time you should at least take a look at the eembc 
benchmarks.  They've spent a lot of effort attempting to put together a 
representative set of loads for benchmarking for embedded applications.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III