These AI kernels would run 50% faster if I were able to compile them with gnueabihf calling conventions. It is a major pain to mix gnueabi and gnueabihf on the same system. Life would be far simpler if AW would provide a gnueabihf version of their libraries.
A huge downside to mixing gnueabi and gnueabihf is that you end up with two copies of all of the system libraries in memory at the same time. For example you have to have two versions of the C run-time, etc, etc.
I've done more benchmarking and it appears that not having gnueabihf hurts AI core performance a lot. On large models like inception it is 50%. On a small model like squeezenet it is 300%. Not having hf is preventing register passing via the FPU registers.
Rasp3b has same quad core Cortex-A7, armv7l as the V5 does. I should be able to get the same benchmark results or very close on the V5. Only significant difference is gnueabihf on Rasp3b.
squeezenet_v1.1
v5 298ms rasp3b 94ms
inception_v3
v5 3592ms rap3b 2074ms
A huge downside to mixing gnueabi and gnueabihf is that you end up with two copies of all of the system libraries in memory at the same time. For example you have to have two versions of the C run-time, etc, etc.
I've done more benchmarking and it appears that not having gnueabihf hurts AI core performance a lot. On large models like inception it is 50%. On a small model like squeezenet it is 300%. Not having hf is preventing register passing via the FPU registers.
Rasp3b has same quad core Cortex-A7, armv7l as the V5 does. I should be able to get the same benchmark results or very close on the V5. Only significant difference is gnueabihf on Rasp3b.
squeezenet_v1.1
v5 298ms rasp3b 94ms
inception_v3
v5 3592ms rap3b 2074ms