5 ms·

Genius! >* 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, w

Genius! >* 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.

nneonneo 3y ago
If I had to guess, it’s a matter of setting up the Huffman tables such that every code ends up with a length of four bits, and then prepending that precomputed Huffman table onto the “compressed” stream. Then you can abuse the zlib library as a decompressor mapping the 4-bit “Huffman” codes to regular bytes. 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?
- Retr0id 3y ago
  Yup, that's pretty much exactly it. .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/blob/8c91eb3edb4424c641b55deef2433ddaf667eebc/bsaes.py#L46 https://github.com/DavidBuchanan314/python-bitsliced-aes/blo...
- 1000thVisitor 3y ago
  > Of course, this won’t be anywhere near as efficient as just implementing the decoder in C > 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?

nneonneo 3y ago

If I had to guess, it’s a matter of setting up the Huffman tables such that every code ends up with a length of four bits, and then prepending that precomputed Huffman table onto the “compressed” stream. Then you can abuse the zlib library as a decompressor mapping the 4-bit “Huffman” codes to regular bytes. 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?

Retr0id 3y ago
Yup, that's pretty much exactly it. .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/blob/8c91eb3edb4424c641b55deef2433ddaf667eebc/bsaes.py#L46 https://github.com/DavidBuchanan314/python-bitsliced-aes/blo...
1000thVisitor 3y ago
> Of course, this won’t be anywhere near as efficient as just implementing the decoder in C > 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?