These results are with the L1 instruction cache on, and branch prediction on. The L2 cache, MMU, and L1 data cache are all off.

The following results were obtained after enabling the MMU and L2 cache. So far the best results are with all caches and branch prediction enabled. Several optimizations have been tested, but few of them produce noticeable improvements.

More detailed results can be found here: arm_vs_mips.pdf

The following things were learned when performing benchmarking:

• Branch prediction is very important
• L1 instruction cache is very important (especially for compute-limited benchmarks)
• L1 data cache provides modest improvements
• L1 data prefetch provides modest improvements
• L2 cache is very important (especially for memory bandwidth-limited benchmarks)
• MMU is very important because it allows caches to be used to their full potential
• Normal memory should be marked as cacheable, inner and outer write-back in translation table entries
• Memory should be marked as non-shareable in translation table entries
• L2 cache controller read, write, and hold delays should be set to their minimums

Details on setting up the caches on the ARM Cortex-A9 MPCore can be found here: Using ARM Caches

Currently LegUp use LLVM to generate ARM assembly, then assembles and links with gcc. If you compile a benchmark with the command:

 make sw ARM_PROFILE=1 

you get instrumented ARM code that counts the cycles for each function, but stops the cycle counters when printf() is called.

 make run_on_board 

will run the code on the ARM on the Cyclone V, and show the profiling data. Profiling events 0x60 and 0x61 show the cycles spent waiting for the ICache and DCache, respectively.

These results are generally 2x-10x better than the older results, shown above.

These results are different for a couple reasons:

• we now run slightly different llvm passes on the IR before it is turned into SW, allowing for different optimizations
• these results do not include printf cycles
• the ARM startup code has been modified a bit, so cache misses now incur fewer idle cycles
• it is also possible that we ran the previous tests with NO_OPT, NO_INLINE, or similar flags.
• allowing clang to produce vectorized code (removing -fno-vectorize -fno-slp-vectorize from CLANG_FLAG) and/or using NEON can also have an impact - some benchmarks get slower, and some faster

LegUp wasn't producing NEON code for ARM by default. With NEON, we get slightly better performance on these benchmarks: