twotwotwo

13 ms·

91.
by twotwotwo 3y ago
It's fun it's exactly 1:1 and you don't need any more output than the state! It's sort of sad it isn't all AES-CTR or ChaCha12. Fast enough not to be the bottleneck in your webpage, and if you find any hint of a pat
92.
by twotwotwo 3y ago
So a nasty form of this, referenced in the post but worth calling out, is that efficiency in one part of the economy can be effectively turned into higher usage elsewhere . If your energy production is cheap enough in terms of variable cos
93.
by twotwotwo 3y ago
It looks like the ones I were PC Magazine, https://books.google.com/books?id=gCfzPMoPJWgC&lpg=PP1&pg=PA... and https://books.google.com/books?id=eX8w8B-OhIIC&lpg=PA371&pg=... . Much apprecia
94.
by twotwotwo 3y ago
It looks like it was Barry Simon in "Lab Notes" in PC Magazine of June and July 1993: https://books.google.com/books?id=gCfzPMoPJWgC&lpg=PP1&pg=PA... https://books.google.com/books?id=eX8w8
95.
by twotwotwo 3y ago
There was a series of articles on lossless and lossy and compression techniques in, I think, PC Magazine that I read as a kid and made a big impression on me. I didn't, like, end up ready to write code to build Huffman trees or anythin
96.
by twotwotwo 3y ago
Those words were about the JPEG recompressor (Brunsli) specifically, which saves about 22% but has a smoother transition from today's .jpg world than any of the new lossy formats; you can bit-for-bit reconstruct the original JPEG from
97.
by twotwotwo 3y ago
Yeah, that is all odd to me; Google cited lack of "interest from the entire ecosystem" ( https://bugs.chromium.org/p/chromium/issues/detail?id=117805... ). Mozilla also had an experimental JXL impleme
98.
by twotwotwo 3y ago
I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to
99.
by twotwotwo 3y ago
A part of this was that zstd and Brotli were able to use compression history windows of MBs not KBs, while DEFLATE maxes out at 32KB. RAM was thousands of times more expensive in the early 90s, so a smaller history window made sense. There
100.
by twotwotwo 4y ago
Could play against adversarial policies become part of the training alongside self-play? It's possible that would be a very slow, essentially "serial" process--adversaries don't really find a new trick until the AI can a
101.
by twotwotwo 4y ago
There are hardware reasons even if you leave any software scaling inefficiency to the side. For tasks that can use lots of threads, modern hardware trades off per-thread performance for getting more overall throughput from a given amount of
102.
by twotwotwo 4y ago
This also relates to something not directly about rustc: many-core CPUs are much easier to get than five years ago, so a CPU-hungry compiler needn't be such a drag if its big jobs can use all your cores.
103.
by twotwotwo 4y ago
This inspired me to dig around a little more, and the details at https://clickhouse.com/docs/en/operations/settings/settings#... leave me more confident you can do large joins if your flow requires the
104.
by twotwotwo 4y ago
Huh! I recently used this to play with CH, and had no idea it was so new! Also, I've been impressed with the range of formats/protocols/types of storage CH can use, and it's a good strategy by the developers because it m
105.
by twotwotwo 4y ago
A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn t
106.
by twotwotwo 4y ago
They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompr
107.
by twotwotwo 4y ago
This is kind of relevant now : Mastodon is seeing a lot of growth all the sudden, the popular server for it is in Rails, and scaling up quickly is a challenge for server operators used to the levels of traffic from two months ago. Twitter
108.
by twotwotwo 4y ago
Title change? The linked content is fine but the submitted title ("Motto: Unsafe languages allow mostly-safe implementations") doesn't appear anywhere in it.
109.
by twotwotwo 4y ago
I think the decision on JPEG XL as a whole is made; there were some statements in favor of adopting it on Chrome's and Mozilla's trackers before the decision from folks at Adobe, Facebook, Intel, and a newspaper, and some develope
110.
by twotwotwo 4y ago
Someone implemented a BPG decoder as a WASM ServiceWorker returning PNG files, an approach that could work even better for Brunsli: https://sequentialread.com/better-portable-graphics-bpg-on-t...
111.
by twotwotwo 4y ago
Apart from numerical or visual comparisons, it does things other formats don't: https://news.ycombinator.com/item?id=27581195 The lossless recompression of existing .jpg content and faster software encoding for its nat
112.
by twotwotwo 4y ago
It's technically possible that, without all of JXL, they could implement the lossless JPEG1 recompressor part (Brunsli) as a Content-Encoding like gzip, which could save about 20% on all the JPEG content out there with no additional lo
113.
by twotwotwo 4y ago
So, the economic value measured for a piece of code drops if fewer people buy the product that it's in or its price has to be cut, entirely separate from how fast anyone is coding. Similar logic applies to a lot of sectors, not just so
114.
by twotwotwo 4y ago
When compressing, window size is a tunable option. I think the compression level sets it implicitly, but it can be set explicitly using brotli -w or windowLog in the advanced zstd API ( https://facebook.github.io/zstd/zs
115.
by twotwotwo 4y ago
For anyone who wants to try this, zstd -T0 uses all your threads to compress, and https://github.com/facebook/zstd has a lot more description. Brotli, https://github.com/google/brotli , is another
116.
by twotwotwo 4y ago
One thing that, for me, sort of undermined the idea of adding strength "around" a weak hash was the multicollisions paper: https://www.iacr.org/archive/crypto2004/31520306/multicollis... Intuitively
117.
by twotwotwo 4y ago
I really appreciate the work that must have gone into narrowing down those bugs. There's a reason for the insistence on multiple independent implementations for new standards; the Internet owes you one.
118.
by twotwotwo 4y ago
> Also super interesting to find out that Deflate was still so suboptimal after all these years. Optimization can be a moving target! Many of these changes only help on newer processors, rather than being speedups that would have worked
119.
by twotwotwo 4y ago
Company: ActionKit (a division of NGP VAN) Company site: https://actionkit.com/ Position(s): Senior software engineer Location: Fully remote in the United States Description: ActionKit is used by over 150 progressive groups
120.
by twotwotwo 4y ago
Agree with GP that this is getting pretty far off the article, but also--I think remote caches in datacenters are sometimes as much about making the cache shared as about the storage latency. If you have a lot of boxes running your applic

More ›