News for hackers. Stuff that matters.

A comment on Lz_xor.

Re:Lz_xor by sedatk on Tuesday August 09, 2022 @07:00PM (#32405715)
I don't understand why the author encodes every literal byte as a separate instruction while in reality, they're just consecutive bytes?

The whole:

  LIT 13
  LIT 24
  LIT 65
  LIT 32
  ...
could have been written as a single instruction:

  LIT [13, 24, 65, 32, ...]
It's almost as if author tries too hard to support their point that their variant looks better.

"Notice how much faster it makes progress through the file vs. LZSS"

Yeah, because you encode every literal separately? It's all LIT instructions?

[ Parent | on HN ]
Re:Lz_xor by puffoflogic on Tuesday August 09, 2022 @08:39PM (#32406566)
Yes and no. The author was making the point that each new LIT relied on an input-dependent branch, whereas when you're decoding XOR [a,b,c] the branch is on the pre-decoded length of the instruction. LIT could be encoded like this but isn't.
[ Parent | on HN ]
Re:Lz_xor by sedatk on Wednesday August 10, 2022 @05:46PM (#32418854)
Got it, there's no "LIT w/length" instruction in LZSS, so it's logically a new compare-and-branch every time a literal character is hit. I hadn't regarded it as a performance-wise argument, but size-wise for some reason.
[ Parent | on HN ]