There are essentially two aspects of CPU performance:
1) How many instructions can the CPU execute in a second.
2) How much actual WORK can the CPU do in one second.
The first is controlled by CPU architecture, memory speed, and so on. The second has those as variables, and add “how effective is the instruction set at doing the sort of work I want to do.” For instance, a PIC16xxx running at 20MHz executes 5 million instructions per second, but those instructions operate on 8bit data, and don’t include things like multiply and divide. But the instructions DO include a bunch of bit manipulation and IO instructions. So if you compare the pic to, oh, the 5MHz 8088 in the original IBM PC (should be safe an inoffensive), the PIC will be faster than the 8088 at some things (in particular those things having to do with touching external hardware), and the 8088 will be faster at other things (16bit math.)
For a long time, people tended to measure CPU performance with floating point benchmarks (fortran geeks they were, every one!) There was a set of benchmarks developed (1972!) called the Whetstone benchmarks that would measure a computers floating point performance. Eventually, people started using computers for things other than math, and realized they needed a similar benchmark for non-floating-point (integer) performance. This led to the Dhrystone benchmarks (get it?)
So the PIC32 runs at 80MHz, and generally executes instructions in about 1 cycle, so it does close to 80MIPs. It also runs the Dhrystone benchmark at about 1.5DMIPS/MHz (also 1.5DMIPs/MIP), which shows a pretty efficient architecture (at the sort of application the Dhrystone measures.) It’s more than a tiny core run at very high speed.
(This is one of the reasons you may have read the messages asking about pin-toggle speed. It’s pretty common for fast CPUs to incur a lot of overhead when they have to talk to the outside world; some of the ARM7TDMI toggle rates are pretty embarassing, and a 3GHz x86 cpu can’t do IO instructions much faster than the ancient 8088 (not to mention the terrible things such instructions do to the pipeline/etc.))
read count : 7