Lime 2 android

[obcd]

I am running some tests on different arm devices.
I basically use the doom speedtest under dosbox, as dosbox is what I am intended to use the device for.
On a zippy tablet with a 1 Gig single core A13 Boxchip, I get approx 11 frames / second
On the Lime 2, I get the same 11 frames / second. So, it looks like the fact that it's dual core doesn't improve speed.
I also tested with an archos game tablet using a rockchip RK 3066 1.6 Gig dual core.
If dual core wouldn't make much difference, I would expect a framerate of 11 * 1.6 = 17,6 frames / second
The test results give me 27,5 frames / second which is approx 1.5 times faster.

So, my question, why is the Lime 2 android so much slower? Maybe both cores aren't pushed to their maximum speed? Maybe there is something wrong with the way I am testing?

[jmyreen]

I am running some tests on different arm devices.
I basically use the doom speedtest under dosbox, as dosbox is what I am intended to use the device for.

A lot of factors come into play here. First of all, dosbox would need to be coded to take advantage of the second core. I very much doubt this is the case.

The performance of a CPU depends on a lot of other things than the raw clock speed. For example, cache memory size plays a big role. The A20 and the Rockchip cores are also based on different ARM architectures, the A20 is a Cortex A7 chip and the Rockchip a Cortex A9. According to Wikipedia https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures, the A9 supports out-of-order speculative execution, whereas the A7 does not.

[obcd]

Thanks for the quick explanation.
I never payed much attention to the fact that the one was A7 and the other A9
The A20 and Rockchip both seem to have the same cache size numbers.
I thought that as soon a program had multiple threads, it could take advantage of a multi core architecture? Isn't it the OS thread scheduler task to assign a thread to one of the cores?
This made me even more curious, so I tried to measure the cpu load while the program was running.
Android usemon shows almost equal activity on both cores. The strange part is that the average load of each core seems to be 50%. This could either mean that program isn't optimally using the cpu resources or that the OS prevents the program to load the cpu close to it's maximum. Another option might be that the test results aren't accurate. If one thread might need all off it's core's power, and the others highly any, you would expect the same average result. Maybe the cpu power hungry thread isn't running on the same core every time. This could explain the behavour as well. It's time for some code analysing, altough I am afraid it will go above my knowledge. 

[jmyreen]

I thought that as soon a program had multiple threads, it could take advantage of a multi core architecture? Isn't it the OS thread scheduler task to assign a thread to one of the cores?

Yes, but this requires the program to be written to start multiple threads. The tricky part is to write the program so that the threads can run in parallel at full speed without the threads needing to wait for the results of the calculations performed in an other thread, or some shared resource. Take Dosbox as an example: the inner loop of Dosbox reads and emulates instructions on a virtual 8086 CPU. You could try to make Dosbox multithreaded so that some instructions are emulated in one thread and the rest of the instructions in another. It would be very difficult to get the threads working at full speed, since each emulated instruction alters the state of the virtual CPU, and the next instruction depends on the new state of the CPU.

This made me even more curious, so I tried to measure the cpu load while the program was running.
Android usemon shows almost equal activity on both cores. The strange part is that the average load of each core seems to be 50%. [...] Maybe the cpu power hungry thread isn't running on the same core every time.

This is most certainly what's happening.