RLE Blitting

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.

I was looking for some efficient alternative to mutexes, which don't put the thread to sleep, but found none, and generally people recommend some nonsense, like refactoring and decoupling the code (wasting a lot of time for nothing), instead of inserting the multithreading as a cheap speedup into the existing codebase. When I suggested the superior alternative to just do while(!signaled); I immediately got downvoted:
https://stackoverflow.com/questions/6460542/performance-of-pthread-mutex-lock-unlock/57749968#57749968

Typically every good answer gets heavily downvoted for offering some simple solution, which is not a "good practice". I.e. you propose using key-value database as an alternative to SQL, but instead of good argumentation against kv dbs, you will hear some autistic screeching about how SQL was the product of much experience, several PhD papers and therefore everyone should follow SQL teaching like it is some holy Quran. Well, you know what? Haskell also grown out of experience of how bad are side effects, and then helped with making PhDs, but you wont be using Haskell in any non-toy project.

Generally there are two kinds of programmers:
1. Programmers who write actual code, which solves the problem.
2. The retards who, instead of code, write unit tests with getters/setters whole time, because it is the "good practice" recommended by some iconic bible by some deranged lunatic like Bjarne Straustrup. These same programming Nazis will scold you for doing "#define PI" instead of "const double pi", using indentation style they dislike (I find it useful putting `;` and `,` before the statements) or not prefixing member variable names with "m_".

Ideally there should be some IQ test, so all such autistic retards could be identified and sent to a country designed for people with special needs. Like they have villages for blind people. Edited on 02/09/2019 21:30.

I was looking for some efficient alternative to pthread mutexes, but found none, and people recommed some retarded shit, like refactoring and decoupling the code, instead of inserting the multithreading as a cheap speedup into existing codebase. When I suggested the superior alternative to just do while(!signaled); I immediately got downvoated by the retards:
I was looking for some efficient alternative to mutexes, which don't put the thread to sleep, but found none, and generally people recommend some nonsense, like refactoring and decoupling the code (wasting a lot of time for nothing), instead of inserting the multithreading as a cheap speedup into the existing codebase. When I suggested the superior alternative to just do while(!signaled); I immediately got downvoted:
https://stackoverflow.com/questions/6460542/performance-of-pthread-mutex-lock-unlock/57749968#57749968

Guess because it is not a good practice. Generally there are two kinds of programmers: those who write actual code, and the retards who write unit tests with getters/setters whole time, because it is the "good practice" recommended by some iconic shitbook by some retard like Bjarne Straustrup. These same retards will scold you for doing "#define PI" instead of "const double pi".
Typically every good answer gets heavily downvoted for offering some simple solution, which is not a "good practice". I.e. you propose using key-value database as an alternative to SQL, but instead of good argumentation against kv dbs, you will hear some autistic screeching about how SQL was the product of much experience, several PhD papers and therefore everyone should follow SQL teaching like it is some holy Quran. Well, you know what? Haskell also grown out of experience of how bad are side effects, and then helped with making PhDs, but you wont be using Haskell in any non-toy project.↵
↵
Generally there are two kinds of programmers:↵
1. Programmers who write actual code, which solves the problem.↵
2. The retards who, instead of code, write unit tests with getters/setters whole time, because it is the "good practice" recommended by some iconic bible by some deranged lunatic like Bjarne Straustrup. These same programming Nazis will scold you for doing "#define PI" instead of "const double pi", using indentation style they dislike (I find it useful putting `;` and `,` before the statements) or not prefixing member variable names with "m_".↵
↵
Ideally there should be some IQ test, so all such autistic retards could be identified and sent to a country designed for people with special needs. Like they have villages for blind people.