poor performance of OpenEmbedded on BeagleBoneBlack compared to Debian

["Peter A. Bigot" <pab@pabigot.com>]

I've been trying to figure out why OpenEmbedded on beaglebone is three 
times slower than Debian on the ray-tracing application described at:

http://scruss.com/blog/2013/09/23/beaglebone-black-slow-as-a-dog/

Part of it is due to meta-yocto-bsp's beaglebone config not enabling CPU 
frequency control (CONFIG_GENERIC_CPUFREQ_CPU0, 
CONFIG_VOLTAGE_DOMAIN_OMAP, and some THERMAL options).  That can be 
fixed for linux-yocto, and isn't an issue with linux-ti-staging, but it 
doesn't eliminate the discrepancies.

With debian, the sample program described in that blog posting runs this 
fast:

   debian@beaglebone:~$ g++ -Ofast -mfloat-abi=hard -o card card.cpp
   debian@beaglebone:~$ time ./card > /dev/null
   real    4m54.846s
   user    4m54.627s
   sys     0m0.057s

With poky master + meta-ti it runs this fast:

   root@beaglebone:~# time ./card > /dev/null
   real    9m37.901s
   user    9m37.200s
   sys     0m0.150s

Still nearly twice as slow.  (With linux-yocto and the default kernel 
configuration it's up around 14m.)

One anomaly I've found is the CPU frequency range.  On debian we have:

   debian@beaglebone:~$ cat 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
   300000 600000 800000 1000000

while on OE we have:

   root@beaglebone:~# cat 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
   300000 600000 720000 800000

So OE isn't allowing the BeagleBoneBlack to run at its maximum speed.  
This isn't enough to explain a nearly 2x performance difference, but 
it's an issue I want resolved.

I've been unable to trace back where these frequencies come from. Could 
somebody tell me what configures the available frequencies for the 
AM335x in linux-ti-staging?

And if anybody has suggestions of where else to look for an explanation, 
I'd appreciate it.  I've tried all the gcc flags I can think of 
(-mcpu=cortex-a8, -mfpu=neon, -mfloat-abi=hard, etc), though I'm going 
to keep poking at it because I still suspect the problem is there.

Thanks.

Peter