A (hopefully) intriguing tangent: at the linked https://bench.nickb.dev/, a 10x increase in iterations on the allocation benchmark results in a change from 28ms to 280ms in Firefox but 44ms to 2800ms in Edge.
WASM compression benchmarks and the cost of missing compression APIs
11–20 of 24 posts
Re: WASM compression benchmarks and the cost of missing compression APIs
#12[deleted]
Re: WASM compression benchmarks and the cost of missing compression APIs
#13Note to author: 120ms is not 66% less than 200ms but 40%.
Re: WASM compression benchmarks and the cost of missing compression APIs
#14Note that both the x and the y axis for Chrome vs Firefox are significantly different.
Also note that it's not clear if a larger bubble is better compression or worse.
Re: WASM compression benchmarks and the cost of missing compression APIs
#15Related to compressing data before storing on SSD: Blosc - faster than memcpy() https://github.com/Blosc/c-blosc On right circumstances Blosc is so fast that even speed ups reading data from RAM (read less, decompress in L1 and L2 caches)
With RAM sizes not keeping up with Moore's Law, it would make sense to have superfast compression as a pervasive, transparent and Hardware-accelerated feature of a modern OS. SIMD provides hw acceleration to some extent, and is clearly well used by the compression algos, its time that compression becomes 'just part of the furniture' as we're now at the stage where compression is fast enough that it can couple with reduced latency (smaller compressed blocks to load into caches reduces total memory latency) to deliver multiplicative speedups.
Re: WASM compression benchmarks and the cost of missing compression APIs
#16The web platform could really use zstd everywhere. As a content encoding for HTTP, and as an API available to JS/wasm. It's really clumsy to use a wasm version of zstd in a JS application because it's hard to get data in and out of wasm efficiently.
Seconded this. I wanted to have a way to stream packets of some really repetitive data to javascript in the browser, and zstd-compressed json with preset dictionary really would have been the best way. Ran into a lot of problems getting zstd ports in web browser working nicely. Ended up just using a handcrafted binary format.
Re: WASM compression benchmarks and the cost of missing compression APIs
#17Just to add a data point, I've written a tiny Rust library [0] that can compile to WASM, that is quite effective for smaller payloads. It is based on PAQ so memory usage explodes a bit once you start compressing large files, but on smaller files it is super competitive.
As far as I can tell the blog author didn't include the 91MB file they used to test the compressors with, so I couldn't give it a try to see how it holds up. I guess 91MB would be too big anyway.
Re: WASM compression benchmarks and the cost of missing compression APIs
#18Related to compressing data before storing on SSD: Blosc - faster than memcpy() https://github.com/Blosc/c-blosc On right circumstances Blosc is so fast that even speed ups reading data from RAM (read less, decompress in L1 and L2 caches)
With RAM sizes not keeping up with Moore's Law, it would make sense to have superfast compression as a pervasive, transparent and Hardware-accelerated feature of a modern OS. SIMD provides hw acceleration to some extent, and is clearly well used by the compression algos, its time that compression becomes 'just part of the furniture' as we're now at the stage where compression is fast enough that it can couple with re…
I can’t find the original source anymore but in this Macrumors post is a quote talking about memory compression in macOS: https://forums.macrumors.com/threads/this-compressed-memory-...
Re: WASM compression benchmarks and the cost of missing compression APIs
#19Related to compressing data before storing on SSD: Blosc - faster than memcpy() https://github.com/Blosc/c-blosc On right circumstances Blosc is so fast that even speed ups reading data from RAM (read less, decompress in L1 and L2 caches)
With RAM sizes not keeping up with Moore's Law, it would make sense to have superfast compression as a pervasive, transparent and Hardware-accelerated feature of a modern OS. SIMD provides hw acceleration to some extent, and is clearly well used by the compression algos, its time that compression becomes 'just part of the furniture' as we're now at the stage where compression is fast enough that it can couple with re…
We do have such stuff. SSDs compress data internally, Linux has transparent memory page compression, Btrfs has transparent compression...
Re: WASM compression benchmarks and the cost of missing compression APIs
#20Related to compressing data before storing on SSD: Blosc - faster than memcpy() https://github.com/Blosc/c-blosc On right circumstances Blosc is so fast that even speed ups reading data from RAM (read less, decompress in L1 and L2 caches)
With RAM sizes not keeping up with Moore's Law, it would make sense to have superfast compression as a pervasive, transparent and Hardware-accelerated feature of a modern OS. SIMD provides hw acceleration to some extent, and is clearly well used by the compression algos, its time that compression becomes 'just part of the furniture' as we're now at the stage where compression is fast enough that it can couple with re…
All major OSes have had transparent memory compression for years now.