Trying to find basic performance measurements of ARM cores

 It can be quite complex as some cores have TCM (tightly coupled memory) which is just another name for a scratchpad (like the one in the Playstation 1). If your code and data are in TCM, other elements of the chip can be doing other stuff in parallel. TCM doesn't collide with FPC bus, for example. The beauty of ARM is that compilers do a very good job so extracting 85-90% of the possible performance isn't tricky but it also has an artful side by which I mean you can dynamically change the cache characteristics (for example), organize preloads (read a byte from almost certainly uncached memory but don't use the result. Take advantage of speculative execution. I admit I've not tried out the really high-performance cores but reading from uncached RAM and then performing an immediate load or logical XOR to the destination register of the read. will render the results of the fetch (which has already begun) invalid so it doesn't stall the pipeline, that can in effect make ALL data and most code appear to come from zero wait-state RAM. If DMA or such is stealing cycles off the bus, Thumb may be of benefit.

 If you have a more specific need, don't be frightened to delve into assembly language. Little things like aligning code & data on cache-line boundaries. 50% of the time that will save a line. If DMA or similar is sharing the same bus as the CPU, Thumb may be of benefit. After all, the machine can read 2 instructions at once. All of the old tricks work fine. From unrolling loops to rewriting the felide constructors. I seem to recall that there are some tricks for converting IEEE 754-1985 standard floats (within certain ranges) to integer without using the FPC. Everything Knuth did, ARM does well at it.

 It can be quite complex as some cores have TCM (tightly coupled memory) which is just another name for a scratchpad (like the one in the Playstation 1). If your code and data are in TCM, other elements of the chip can be doing other stuff in parallel. TCM doesn't collide with FPC bus, for example. The beauty of ARM is that compilers do a very good job so extracting 85-90% of the possible performance isn't tricky but it also has an artful side by which I mean you can dynamically change the cache characteristics (for example), organize preloads (read a byte from almost certainly uncached memory but don't use the result. Take advantage of speculative execution. I admit I've not tried out the really high-performance cores but reading from uncached RAM and then performing an immediate load or logical XOR to the destination register of the read. will render the results of the fetch (which has already begun) invalid so it doesn't stall the pipeline, that can in effect make ALL data and most code appear to come from zero wait-state RAM. If DMA or such is stealing cycles off the bus, Thumb may be of benefit.

 If you have a more specific need, don't be frightened to delve into assembly language. Little things like aligning code & data on cache-line boundaries. 50% of the time that will save a line. If DMA or similar is sharing the same bus as the CPU, Thumb may be of benefit. After all, the machine can read 2 instructions at once. All of the old tricks work fine. From unrolling loops to rewriting the felide constructors. I seem to recall that there are some tricks for converting IEEE 754-1985 standard floats (within certain ranges) to integer without using the FPC. Everything Knuth did, ARM does well at it.