Hilarious critique. If you weren't as mathematically illiterate as you likely are, you would know how general matrix operations are, and how essentially any algorithm (including human cognition) can be implemented using them as an intermediate.
I'm not. But I'll concede you are possibly more literate - I won't dox myself on this account.
Congratulations.
If you honestly argue that LLM computation and human cognition are equivalent there is no further argument to be had - it's immediately a philosophical or worse a religious argument that cannot be won.
However, that we're even arguing on that level baffles me. How did this happen! They're glorified calculators.
They really marketed the hell (sorry) out of LLMs.
> uses a specific, objectively nonsensical critique of LLMs (the idea that an algorithm using matrix operations as a primitive cannot emulate "true" intelligence)
> receives pushback on the specific, objectively nonsensical critique
> "oh so you're saying that LLM computation and human cognition are equivalent? they're glorified calculators that disprove the Jacobian conjecture!!!"
You have unduly assumed that «drop the abuse» implied an «abuse digital minds».
"Expletives" are part of the proper description of facts (typically "to be judged as such") - they are part of the serious assessment of things and as such are normally found. There is no legitimate assumption from the post that they may have been used as gratuitous insults.
"Thinking" seems to be a political term now, people have completely different definitions of it, based on how they wish the world to be organised, and find defining it differently offensive.
Which is great and please don't take this as me being critical of the approach you are taking. I think it's perfectly reasonable during early development have your compressed stream in flux.
I've been bitten in the past with other libs that weren't as explicit about their stability.
I haven't implemented any ARM-specific dispatch yet (there are currently no NEON paths for vector ops either, and we instead trust the compiler to autovectorize), and will do so for upcoming versions.
So it's essentially "LZ4 unshackled". I've made several modifications to the LZ4 format, most of which are in service of eliminating branches/making them more predictable, and making decompression very friendly to out-of-order cores by hiding false data dependencies behind a rarely taken branch (similar to this: https://news.ycombinator.com/item?id=48889148).
Some concrete changes in the format are:
- match length per block is capped to 32
- distance to a match must be >= a fixed constant
- unlike lz4, tokens and literals have separate streams
- format of the token byte has been changed
Now, this format allows our decompressor's hot loop to be very simple (in terms of the number of branches it has). This simplicity in turn allows our compressor to create a compressed stream that is friendly to the (small number of) branches in the decompressor.
The experimental compression modes (see readme) attempt to exploit this even further (but are even slower at compression). I define a "cost", which is a linear function of the branches induced by a compressed stream (this function serves as a proxy for decompression time), and then do a DP to minimise this cost.
Almost none. Once again, simplicity comes to our rescue here. The decompressor is simple and a naive safe version I implemented but haven't merged into main yet (see: https://encode.su/threads/4514-misa77-ridiculously-fast-deco...) is only ~5% slower than the current unsafe version (and can very likely be made faster).
In particular, on even moderately compressible data most blocks take the following form:
- 1 token byte + 2 distance bytes
- a somewhat unpredictable number of literal bytes
If these streams are interleaved, then it's harder for the out-of-order core to process the token bytes of several blocks in advance (as the position of the next token byte depends on the unpredictable number of literal bytes in the current block). However, if you separate them (all token bytes in a prefix, and literal bytes in a suffix), the CPU can speculatively parse token bytes of a lot of blocks in advance (as most of the time, it just has to step forward by three bytes to go to the next block's token byte).
I used the same "separate stream" design (one of them coded backwards from the end, to eliminate the need to send a separate offset) when working on video compression, to separate out arithmetic-coded bits from literal bits. It's a good idea. The only reason it isn't in AV1 is because hardware wanted to do DRM decryption in order.
misa77 primarily targets textual data (ie. byte-aligned data formats where each byte corresponds to a symbol), so I hadn't tested it on game assets much until now.
After seeing your comment, I pulled some random assets from Pathfinder WoTR (in fact, Unity compresses them with lz4hc) and DOS2. The gains are much more modest here due to asset data being mostly floats, but level 0 performs decently nevertheless.
