Rendered at 18:00:58 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
wolf550e 4 minutes ago [-]
From status in readme in github:
- misa77's format may change unexpectedly as it's still v0.x.y.
- The decoder assumes that the input is a valid misa77 stream. Invalid input is UB and I offer no guarantees for whatever misa77 does in this case.
- It's been through some local fuzzing but is not hardened, so treat it as experimental.
kazinator 9 minutes ago [-]
[delayed]
scottchiefbaker 21 minutes ago [-]
Almost double the decompression speed, *and* a higher compression ratio than LZ4? That's very promising.
I don't see much in your README that talks about how a developer would integrate misa into their code. I might suggest some basic code samples to help a developer integrate misa decode into their project.
Congrats, looks like a cool project.
logdahl 29 minutes ago [-]
Nice results, I will keep a watch on this! Would be interesting to see benchmarks vs Oodle compression, I think the most similar one is Selkie?
bootlegbilly 1 hours ago [-]
this is super interesting! im excited to give this a look this afternoon, since I specifically have wanted faster throughout for decompressing maps in a game engine.
nonadhocproblem 17 minutes ago [-]
Hey, glad to hear that you found it interesting.
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.
Note: the benchmarking setup is identical to the intel x86-64 one described in the readme.
Sesse__ 28 minutes ago [-]
Interesting, but if you are not robust to corrupted/malicious data, it is really in a different class of algorithm and it is hard to compare speeds directly.
From memory, 2505 MB/sec also sounds on the low side for LZ4 on a modern CPU?
In short, my decompressor is very simple, and a naive safe version of the decompressor is only about 5% slower than the current unsafe one (and I will add this safe version in v0.3.0).
As for the raw throughput numbers being low here, it's because Intel Turbo (frequency boost) was disabled for stability, and the CPU was running at a fixed frequency of 2.1 GHz (I've confirmed that the relative performance scales similarly even with Turbo enabled).
actionfromafar 16 minutes ago [-]
You mean some kind of error detection? LZ4 doesn't have that.
kzrdude 9 minutes ago [-]
Have defined behaviour on any input, i.e not causing security issues, memory safety issues on untrusted inputs. Lz4 has this.
- misa77's format may change unexpectedly as it's still v0.x.y.
- The decoder assumes that the input is a valid misa77 stream. Invalid input is UB and I offer no guarantees for whatever misa77 does in this case.
- It's been through some local fuzzing but is not hardened, so treat it as experimental.
I don't see much in your README that talks about how a developer would integrate misa into their code. I might suggest some basic code samples to help a developer integrate misa decode into their project.
Congrats, looks like a cool project.
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.
Results on a map asset (WoTR):
Results on equipment asset (WoTR): Results on texture asset (DOS2): Note: the benchmarking setup is identical to the intel x86-64 one described in the readme.From memory, 2505 MB/sec also sounds on the low side for LZ4 on a modern CPU?
In short, my decompressor is very simple, and a naive safe version of the decompressor is only about 5% slower than the current unsafe one (and I will add this safe version in v0.3.0).
As for the raw throughput numbers being low here, it's because Intel Turbo (frequency boost) was disabled for stability, and the CPU was running at a fixed frequency of 2.1 GHz (I've confirmed that the relative performance scales similarly even with Turbo enabled).