2013-07-15 09:50 AM
Hi ,
I am working on Cortex M4F CPU , its 168 MHZ , i know that Cortex M4F is 1.25 MIPS per MHZ so a quick calculation will give me total of 210 MIPS . Lets say i have an algorithm that runs 3 seconds , so what should i say for example to the costumer , if you want a 3 second performance you need to give me a CPU that is able to give me 210 MIPS ? suppose its true , i have few follow up questions : 1. Performance is also effected by various factors ,for example : using the FPU , the DSP capabilities of the CPU , the speed of the SDIO interface , the file system implementation , and event the SD-card class , so given this factors , the 210 MIPS is a really a rough estimation , correct? 2. Who also can say that in the whole 3 seconds of my run-time i am using all of the 210 available MIPS , maybe i am using in average only 60% 70% of my CPU ? will measuring the average CPU consumption give me a better estimate on how much MIPS that i am using? (Suppose i am using only 50% of the CPU average,so with that i need only 105 MIPS and not 210 MIPS , correct?) Thanks #mips2013-07-15 12:37 PM
I have doubts about the value of a MIPS rating for embedded controllers because it doesn't tell me much about what I can expect from the chip. If an M4 and an 8051 have the same MIPS/MHz rating does that mean they would be equivalent at the same clock rate...even though the 8-bit 8051 with poor memory referencing instructions might take as much as 10 times longer performing 32 bit integer calculations?
If I'm streaming large blocks in/out an SPI or USART port, does the same MIPS rating on two different M4 cores mean they are equal if one (i.e. ST) has a DMA controller that can run in parallel with CCM RAM to transfer those large blocks with virtually no impact on CPU time, versus another vendor's M4 that uses interrupt per character or cycle stealing DMA through a single port SRAM? Not even close. MIPS helps the evaluation when looking at algorithm speed. I have a complex wave shaping function that runs motors with an interrupt service of about 40% of the CPU, so those extra MIPS going from an M3 to an M4 were significant, especially with the added DSP instructions. The interrupt time I gained from the faster clock, better instructions and CCM memory allowed me to add more functionality on the communications side. But the raw clock speed and MIPS rating were incidental relative to the benefit of moving internal RAM access to the CCM memory and out of bus contention with DMA. The MIPS rating didn't help much in that regard. Look at the overall architecture more than MIPS. Above all, think parallel, how many things can I do at the same time, especially with DMA and DSP intsructions? As Spock once said, ''his pattern indicates two-dimensional thinking''... or linear thinking. Jack Peacock2013-07-16 01:12 AM
I have doubts about the value of a MIPS rating ...
Me too. There is a nice example somewhere in the ARM documentation, showing disassembled code for a 16-bit addition on a 8-bit MCU, 16-bit MCU and 32-bit MCU. While the 8-bit MCU needs about 30 instructions, the 16-bit MCU needs 4 or five, and the 32-bit MCU just one. The point is - what is the core getting done in this instructions. There are other benchmark test like , which are more reflective of real-world performance.If I'm streaming large blocks in/out an SPI or USART port, ...
That is also true. More general, a microcontroller is much more living from it's peripheral units than from it's core performance. Flexible DMA and high-performing, interconnectable peripherals are much more interesting for professional users than a fast core. I know of examples where a lame, outdated PIC16 MCU was chosen over an ARM Cortex, simply because the peripherals did the job alone once initialised.
2013-07-16 07:53 AM
I would agree with the other posters. MIPS doesn't tell me enough and how does one map MIPS to real world algorithms. There are interrupts, DMA, peripherals, RTOS, ....
The customer needs to understand the risks of specifying a less than adequate CPU.Customers are notorious for feature creep and feature addition once initial functionality is obtained. If the CPU was minimally spec'ed, then you might be stuck.Customers will understand spread sheets showing the cost of development vs cost of goods. Unless you are shipping a large volume (work the numbers) , the cost of development is far greater. Then there is maintenance, upgrades, additional features, ...Time is more expensive than hardware.2013-07-17 12:49 AM
Yes i agree with you all , that what i was exactly thinking.
Thanks all !2013-07-18 08:26 AM
Important note: ST (and ARM) use the rating DMIPS/MHz. DMIPS are not MIPS, per se, they are a unit of the Dhrystone benchmark.
So, an 8051 with the same MIPS will always score much lower in DMIPS. Granted, DMIPS are biased toward larger bit architectures. If you can get away with 16 bit math, for example, a 16 bit device may have the same real-world performance for your app than a 32 bit device would.In any case, DMIPS are a reasonably good, general measure of a CPUs performance.