Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

RLE Blitting

Name: Anonymous 2019-08-17 15:20

Ok. Transitioning to RLE blitting haven't improved the performance that much - just 20% speedup, but code complexity greatly increased. One thing I noticed while measuring performance (for both rle and non-rle code) was that at times my static code completed two times faster, which is impossible because test used all static data (a sprite which it blitted a million of times in a loop), with only variables being branch prediction and I have 0% CPU load, and it doesn't make any syscall inside measured code. What does that even mean? Branch misprediction does affect performance, but not two times in the long run, because it would quickly retrain the cache on thousandth iteration.

Broken scheduling or OSX intentionally slowing down the code? Or maybe the Intel CPU itself does that? My MacBook is relatively old, so if it has any time bomb, it would be activated by now. Or maybe that is the infamous Meltdown fix slowing down my code two times? How does one disable the Meltdown patch? For Linux there is https://make-linux-fast-again.com/, but what about OSX? I don't care about security - it is overrated.

Name: Anonymous 2019-09-04 7:01

>>46
busy waiting is slow as fuck compared to waiting on a mutex though. your're are hogging a core with constant checks of the volatile variable, negating most of the things you gain by spawning a thread. an alternative that would be faster and avoid most of the mutex-related overhead (but would be fairly risky when it comes to race conditions/deadlocks/livelocks) would be a busy wait coupled with a usleep().

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List