>* the state of the cells is being stored in a big array, accessed via the get_cell and set_cell helper functions. What if instead of using an array, we stored the whole state in one very long integer, and used SWAB arithmetic to process the whole thing at once?*
I’m really curious as to how the unpacking of this long integer into pixels on the screen doesn’t add more overhead than it saves. I guess I’ll have to wait for your next one on the compressed gzip stream hack.
Of course, this won’t be anywhere near as efficient as just implementing the decoder in C, as Huffman decoding needs to be much more general than just unpacking fixed-width chunks. But it will definitely be an improvement over naive loops.
I wonder whether .hex() could be pressed into service as a very scuffed 4-bit unpacker? Maybe something like .hex().encode().translate() to get an arbitrary palette mapping?
.hex() is a good idea, and probably has a decent chance of beating gzip, assuming .translate() is fast enough.
The fastest approach for the bitsliced AES impl ended up being pretty cursed: https://github.com/DavidBuchanan314/python-bitsliced-aes/blo...
> It is quite easy to add new built-in modules to Python, if you know how to program in C. Such extension modules can do two things that can’t be done directly in Python: they can implement new built-in object types, and they can call C library functions and system calls.
Then why are you talking about this instead of extension modules?