I have refactor the threading stuff. With
https://github.com/jedie/DragonPy/commi ... 64bb3660e9 i used only Tkinter after() and recalculate the CPU burst count dynamiclly.
Seems that's this is a better solution than before and much simpler. The benchmark cycles/sec values are nearly the same as with the complete GUI. So the GUI didn't produce much overhead in the current implementation
With PyPy2 it looks like this:
PyPy does 750.000 Ops from 6809 CPU in 0.1 Sec
If i calculate the 35 Mio cycles/sec with the 6.2 Mio. Ops/sec, than i came to avg. 5,6 MPU Cycles pro Op... Seems to be possible if i looked into the 6809 Instruction set table, isn't it?
I retest the PyPy Benchmark with different loops, because PyPy needs a few loops to optimize the JIT:
--loops 1 -> 2,4 Mio CPU Cycles/sec - duration 0,60 Sec
--loops 2 -> 4,2 Mio CPU Cycles/sec - duration 0,70 Sec
--loops 5 -> 8,7 Mio CPU Cycles/sec - duration 0,85 Sec
--loops 10 -> 14 Mio CPU Cycles/sec - duration 1,0 Sec
--loops 20 -> 20 Mio CPU Cycles/sec - duration 1,5 Sec
--loops 50 -> 28 Mio CPU Cycles/sec - duration 2,6 Sec
--loops 100 -> 33 Mio CPU Cycles/sec - duration 4,5 Sec
--loops 250 -> 35 Mio CPU Cycles/sec - duration 10 Sec
--loops 500 -> 37 Mio CPU Cycles/sec - duration 19 Sec
--loops 1000 -> 38 Mio CPU Cycles/sec - duration 39 Sec