I've seen a significant performance difference between the latest v0.2.2 and v0.2.1b.
For this particular cart, it runs significantly slower on the latest version when measured with a stop watch, but when using the stat(1), the system claims the opposite--i.e. that it's faster. (These are both being run from the .exe on Windows.)
Version stat(1) Stopwatch Timed v0.2.1b 285 30 seconds v0.2.2 219 8 minutes, 14 seconds |
I've included the cart for reference.
-ElectricGryphon
massive use of binary functions vs ‘operators’ (like >>,|,...)?
did you try replacing those?
(doc states that they are no longer compensated and were explicitly made to be slower!)
That’s a good thing to look into.
I was wondering about garbage collection because there was such a difference between reported speed in stat 1 and measured/times host system speed. Each pixel has a lot of functions that get called (though no recursion in this case) so I could see this thrashing the stack or however LUA manages memory.
Of course the other likely explanation is that I’ve got something sketchy in my code that is just catching up with me now.
I’ve got it running with a flip before the draw function so that it’s forced to show the screen updates.
I need to look into this more, but yes -- it seems that this is caused by stat(1) giving incorrect results, which in turn is triggering more yields at this line:
if(stat(1)>.75)yield()
I tried removing this line, and get a stopwatch time of ~24.5 seconds. I also tried a version with all the band(),shr() etc. calls replaced with faster operator versions (&, >> ..), and it makes little difference, so I think we can ignore that in this case. Here's that version if you're curious: LOAD #render_speed_dif_zep
It's interesting also that the bad stat(1) results / slowdown seems to start around 10% of the way through. Definitely something funky going on! Will try to get this fixed for 0.2.2b
Awesome thanks! I forgot that I had the odd stat 1 yield thing in there...
Turns out this uncovered quite a subtle bug in the cpu counting when ending a frame with yield() instead of flip() -- fixed for 0.2.2b (will be live in the web player in the next couple of days). Thanks for the heads up!
[Please log in to post a comment]
