Written in hand-optimized assembly with individual implementation for every CPU on the planet, with integer division function in 10000 lines of code impelented with XOR and bit-shifting which is somehow 0.3% faster than CPU built-in division operation.
He had to de-optimize the init sequence because the little trick he added that caused the init sequence to return a little power to the grid instead of taking it was causing grid stability issues because the returned power from offices starting up was a bit higher than the extra power required for factory startup weekday mornings.
The mention of division has triggered a memory. I think I actually saw a library like that once. It was in C, not assembly, and was almost certainly for one specific architecture (probably Intel), but other than that, there was a lot of low-level stuff that claimed to make division faster for all CPU-native data types.
It was above my skill level to just pick up and use, let alone read and understand, but I can tell you that it at least looked legit, and the author seemed earnest in their description, so something like your hypothetical is very much out there.
There is a video where a real game dev was showing how bad a specific benchmark was. It was basically read arguments, get a random number, do a for loop 10,000 times, inside there do another for loop 10,000 times, do some equation with a modulo, put result in array, pick a number from array and print to screen.
The biggest time cost was the modulo as that’s the hot path. He basically went through and typecast all the ints to double. He got 4x the speed. It went from almost 2 seconds to less than 0.5 second just on that change. This is mostly due to cpu and compiler now using simd instructions.
Yeah, I’ve actually written quick and dirty code that used both a division and a modulus, but then went back later to use the former to calculate the latter with a multiplication and a subtraction to get a speed improvement.
There have been other occasions where I’ve been able to replace something like average = sum / count; if average > y with ifsum > count * y, when it’s not entirely obvious that y could be multiplied by anything and remain meaningful.
But when a division can’t be avoided, you still want that genius-written magical library to take some of the sting out of it.
Bless Ronald
Our math depends on him 🙏
Written in hand-optimized assembly with individual implementation for every CPU on the planet, with integer division function in 10000 lines of code impelented with XOR and bit-shifting which is somehow 0.3% faster than CPU built-in division operation.
He had to de-optimize the init sequence because the little trick he added that caused the init sequence to return a little power to the grid instead of taking it was causing grid stability issues because the returned power from offices starting up was a bit higher than the extra power required for factory startup weekday mornings.
I love that this is an actual possibility.
The mention of division has triggered a memory. I think I actually saw a library like that once. It was in C, not assembly, and was almost certainly for one specific architecture (probably Intel), but other than that, there was a lot of low-level stuff that claimed to make division faster for all CPU-native data types.
It was above my skill level to just pick up and use, let alone read and understand, but I can tell you that it at least looked legit, and the author seemed earnest in their description, so something like your hypothetical is very much out there.
There is a video where a real game dev was showing how bad a specific benchmark was. It was basically read arguments, get a random number, do a for loop 10,000 times, inside there do another for loop 10,000 times, do some equation with a modulo, put result in array, pick a number from array and print to screen.
The biggest time cost was the modulo as that’s the hot path. He basically went through and typecast all the ints to double. He got 4x the speed. It went from almost 2 seconds to less than 0.5 second just on that change. This is mostly due to cpu and compiler now using simd instructions.
Small changes can have big impacts.
Yeah, I’ve actually written quick and dirty code that used both a division and a modulus, but then went back later to use the former to calculate the latter with a multiplication and a subtraction to get a speed improvement.
There have been other occasions where I’ve been able to replace something like
average = sum / count; if average > ywithif sum > count * y, when it’s not entirely obvious that y could be multiplied by anything and remain meaningful.But when a division can’t be avoided, you still want that genius-written magical library to take some of the sting out of it.
He didn’t do any of that. Just typecast the numbers to be doubles.
The whole benchmark was a mess but that part specifically surprised me.