Log In  

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

Cart #render_speed_dif-0 | 2021-02-18 | Code ▽ | Embed ▽ | No License

P#87830 2021-02-18 06:27

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!)

P#87832 2021-02-18 09:07 ( Edited 2021-02-18 15:22)

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.

P#87847 2021-02-18 16:17

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

P#87848 2021-02-18 17:41
1

Awesome thanks! I forgot that I had the odd stat 1 yield thing in there...

P#87849 2021-02-18 18:07
2

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!

P#88076 2021-02-23 22:18

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 06:20:40 | 0.011s | Q:22