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.
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.