Notices by Paul Khuong (pkhuong@discuss.systems)

@whitequark for medium sized docs, I've had a hard time justifying better compression algorithms than gzip, since gz encoding is so widely supported you can almost blindly stick verbatim it in your response. zstd soon though.

API design q: how much do we hate the implicit transform stack in opengl?

@whitequark @jann p99.9 on real S3 is surprisingly trash. You need request hedging for reasonable tail latencies… but I have no idea if that even work on S3-compatible service of the day.

is there a nice replacement for std::sort that's a lot smaller, even if slower?

@whitequark @hailey one of the most infuriating moments using rust async was when I used block_on to hide async implementation details, and that worked fine in a blocking context (with C in the middle of the call stack). But then someone used the same code in an async context, and that panicked.

@hailey The problem is that async runtimes want to take over the whole execution, so any component that wants to be explicit about exposing concurrency in its implementation ends up leaking in callers that don't, or has to implement an inefficient adapter. There wouldn't be a colouring problem if it were easy to block on async values and return the result the same way as a blocking call. But no, my microbenchmarks!

@dalias @ireneista @zzt i worked at a place that did that and it was non-trivial to find significant space improvements. I don't think it makes sense to claim JSON is necessarily orders of magnitude larger than a raw binary representation and that the memcpy yardstick is thus a useless metric. Or at least, it makes as much sense as claiming the same for fixed width VS variable width binary.

@dalias @ireneista @zzt arrays are valid json. That's equally extensible as raw binary.

@dalias @ireneista @zzt all I'm saying is that json can be smaller than a binary fixed width format. So it's not obvious to me why the memcpy comparison is necessarily garbage.

@ireneista @zzt I'm saying json can be smaller than binary when the latter is fixed width for the worst case. ASCII decimal gets you slightly over 3.3 bits/byte. Fixed width binary is 8b/B, but must be sized for the worst case, often with coarse granularity (1, 2, 4, or 8 bytes). It's not rare for the typical value < sqrt(worst case), especially once the worst case is rounded up to a nice bitwidth.

@dalias @lritter pretty sure you can bucket iterators by ctz of their index, and keep the highest indexed iterator in each bucket.

@lritter @dalias you keep log n copies of earlier iterators (and always keep a copy of the initial iterator). The copies are more dense when you're closer to the current location (and fully dense just before)

@dalias @whitequark a lot of time devs don't want to tweak their crash reporter integration to filter out sensitive data, so the crash reporting server has to do it after the fact :/

@jj git fetch/git reset?

@mcc movzx/sx for widening. regular mov for narrowing, but be mindful of partial dependencies on 8 and 16 bit destinations (16b in particular).

The size suffix is an at&t special and not part of the ISA (which also has movd/movq…)

@cr1901 @mcc 16 bit ops are extra slow nowadays (no one uses them).

So, the MOAR LAYERS folks like log-sum-exp… do we know if one tried to replace log with a bitcast of float to int, and exp with the reverse? In a float world, the cost is int -> float after bitcast, and float -> int before bitcast.

Let's say you know the input is an exact multiple of your integer divisor. Does that let you come up with a smaller div-by-mul constant?

EDIT: I don't mean a reciprocal inverse mod 2^w, but literally a fixed point div by mul (which also avoids the need to ensure the divisor is odd).

https://discuss.systems/@pkhuong/113663255154088174