[sdiy] Small MCU MIPS, DMIPS?

Tue Mar 1 01:40:20 CET 2011

karl dalen <dalenkarl at yahoo.se> wrote:
>>Scott Gravenhorst <music.maker at gte.net>
>> I disagree with the premise that it's useless, meaningless
>> or just marketing blather.
>> 
>> Why don't YOU tell us exactly how we should measure it?
>
>Dear Scott, that was not the point of this post,ofcourse
>we want as many MIPS "whatever" we can get, one point i now
>remember is that it's quite easy go into micro optimizing
>code by ASM in the belief that we actually gain something.

Sometimes yes, sometimes no.  I do assembly and where it counts, I add up the
cycles each instruction takes (assuming it's not a device that executes all
instructions in one clock).  But this is hand optimization and your milage may vary.

>I have found after several experiments whatever code i
>optimize are later destroyed and improved by the optimizer!

But that isn't the fault of the IC and it's MIPS rating, that's an attribute of
an optimizer and your first post didn't mention that.  It appeared to me that you
doubted that there was any value in MIPS at all (being just marketing blather)
and I was trying to point out that it isn't valueless, but it also isn't the
final word.

>That's great for crap software writer as me but yet i have
>a hard time to believe that a supreme software writer will
>outperform todays optimizers. They might but to what cost?

Surely, and the cost would be some hours.  Hobby stuff as I do is a labor of
love, so I don't worry too much about the hours, rather it is the result.  And
for me, the hours spent are also a learning experience so that I don't repeat
mistakes.

>> The actual application is most important since it may or
>> may not be able to use the special features provided.
>> Application X on device A may run faster than on device
>> B, and application Y might run faster on device B
>> than on A.  So which device is faster?  That
>> question is of little value. 
>
>That question are of important matter, as suggested the
>fact the dsPIC has dual ported RAM for DMA transfer as
>STM32 uses arbitration but i may have missed the exact
>implementation of STM32 DMA.

As I wrote previously, - your particular application is going to be the
determining factor.  Given the right features for the specific application, where
there is, for example, parallelism that your application takes advantage of, it
could be possible that a slower MIPS device might actually outperform a faster
MIPS device.  Unless you are capable of doing a cycle by cycle analysis of code
using those features, A benchmark based on your application will tell you.  If
the issue is the DMA, then you need to command an understanding of exactly how it
works since it's timing could be important - for your application.

>> So do your research, read the datasheets of the devices you
>> are considering and understand how the features will affect
>> the application you want to implement.  That will tell you
>> more than MIPS - for  YOUR application.
>
>Yes thats alright for restricted application but when you want
>to do those extra things it might very well show up that a
>switch to another device on the premises of more MIPS in
>the end be no more MIPS, in fact less because of those
>extra things that needs to be implemented.

Aren't those "extra things" that "need to be implemented" just attributes of the
application?

>Besides we can all read data sheets until our eyes bleed
>yet not being able to gain those extra Mips due to a vast
>number of circumstances. it's one thing for DIY and completely
>different for big companies that uses millions of devices but
>i really wonder if they spend the time and money doing those
>MIPS comparisons when a STM32 cost like 2euro in single units.

As I said, MIPS is useful for selecting a few devices from the many offered and
to benchmark using your application as the test case.  If you're considering the
STM32 versus the dsPIC, the best way to know which is faster for your application
is to acquire them and do the benchmark.  I realize that you'd prefer not to
write the application twice, but you don't have to if you use C.  Just recompile.
 And with optimizers, you will get a good idea of how good or bad the combination
of the chip and the compiler is.  Surely a good chip with a crappy compiler could
yield a poorly performing result and vice versa.  I think that a company that
does this stuff would look at MIPS as I described - a general marker and would do
benchmarks themselves that consider the intended application since saving a dime
on 10 million units can effect the bottom line, which if significant enough will
make the decision for them.

>> However, generally, MIPS is a basic starting point for a
>> very general comparison of the devices you would consider.
>
>Better then nothing perhaps.

Yes, and I doubt that the chip mfr would say much different.

>> I don't believe that any engineer would consider MIPS rating
>> the ultimate answer, when they need a device, they will 
>> get/buy samples and benchmark themselves. But MIPS will
>> help them choose a few from the many.
>
>yes, but where do YOU draw the selection line and on which premises?
>I bet it could be a cumbersome decision. 

I benchmark when it's that important.  And yes, it's not an easy decision always.
 It would be like buying a car based on the engine's peak horsepower rating
without test driving it.

>MIPS as i recall, where based on a VAX computer measurement
>not very applicable onto todays MCU's? No/Yes?

(I worked for DEC years ago)  Yes, I believe that it was introduced by DEC for
the VAX.  But it's just an acronym that stands for Millions of Instructions Per
Second, nothing more.  The instruction set makes a big difference - the VAX was
not a RISC and MIPS on a RISC could be very high, but the fact that one uses more
instructions to complete a given basic task means that it could run slower than a
CISC of lower MIPS rating.  Benchmark.  That's why your application is so
important - it may or may not take advantage of the features provided - if it
can't use certain features, then the device might be insufficient, however,
benchmark is the only way to know for sure, especially given that the compilers
for different devices will not be the same and will have different optimization
features depending on the specific device enhancements.  Bottom line is that MIPS
is what it is and it is useful for a very raw comparison and nothing more -
mainly to help engineers decide which several devices to test from the many that
are offered.  I think that actually MIPS is more meaningful for microprocessors
than it was for a VAX since the VAX instuction set had a single instruction for
evaluating polynomials.  Most microprocessors are much closer to RISC than a VAX.
 Datasheets will tell you where on the scale of RISC to CISC the device sits, but
the final answer is a real benchmark based on your app.

>Anyhow in 10 years time MIPS are no more parameter to select from 
>since then we will be using carbon based MCUs at +1Thz.Transistors
>are already made at these speeds in labs.

Heh, well, then it will be TIPS, no?  but still useful as a very basic
comparison.  MFLOPS, GFLOPS too...

>Reg
>KD (reserves for being all wrong in my assumptions)
>
>
>_______________________________________________
>Synth-diy mailing list
>Synth-diy at dropmix.xs4all.nl
>http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>

-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/
-- FatMan: home1.gte.net/res0658s/fatman/
-- NonFatMan: home1.gte.net/res0658s/electronics/
-- When the going gets tough, the tough use the command line.