# Calculate algorithm's MIPS from cycles?

My audio DSP algorithm processes input sound file (45 seconds, 16 kHz, mono). After simulation is done, gprof profiler tells me:

Cycles: total = 6846310893.

My target DSP processor is 600 MHz and executes 1 instruction per cycle, meaning it is 600 "MIPS" (millions of instructions per second).

How much will this algorithm (runnig real-time) take out of those 600 MIPS? Can this at all be calculated using above data?

• Naive way is to do 6 846 310 893 / 45 = 152 140 242 ~ 152 MIPS , right? – jojek Feb 8 '18 at 8:55
• That gives cycles/second, I don't thing it's MIPS. – Danijel Feb 8 '18 at 9:00
• Assuming that one instruction takes a single cycle then you get MIPS. – jojek Feb 8 '18 at 9:04
• Um, gprof is a code instrumenter that works on native binaries, right? Unless the machine you ran gprof with your binary on has exactly the same architecture and memory latencies as your DSP, you can't derive much from that cycles measurement. – Marcus Müller Feb 8 '18 at 9:04
• Not completely sure, but I think @jojek's thinking is OK. jojek, could you add that as answer? – Danijel Feb 15 '18 at 12:55

The Naive way is to do 6 846 310 893 / 45 = 152 140 242 ~ 152 MIPS. This makes an assumption that each instruction takes exactly one cycle on your processor.

Another approach would be to use tool such as massif and estimate the MIPS using a file of the known length (45 seconds in your case).

valgrind --tool=massif --stacks=yes --detailed-freq=100 --massif-out-file=out.msf your_binary
ms_print --threshold=100 out.msf


Then at the bottom you will get something like:

--------------------------------------------------------------------------------
n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
81        721,831              600                0             0          600
82        728,199              448                0             0          448


Take the final value for time(i), divide it by the number of seconds and by $1e6$. The result should be your approximate MIPS.

The CPU's datasheet will provide information about how many cycles each command requires (e.g. in here look for "cycles", and with something like this you can also work out what else might a command require to determine if additional cycles will be required). Sometimes they might differ (for the same command), depending on the operands.

What you can do is disassemble the processing part, look at the set (i.e. unique) of commands that are used, look up how many cycles they take on average and from that, work-out a best-case / worst-case scenario for your algorithm (taking also into account how many times each command is used, potentially even, in a loop).

If you are already at a low-enough level, so that you are sure about what commands have been used, then your estimate will be closer to the real value.

Hope this helps.