lq0000

I collected some more measurements with different implementations of the get function.

1000000 iterations, buffer 8192, message 128

i9-13900K, gcc 13.3, -O3, kernel 6.8.0-49, glibc 2.39

byte-mod: 0.117353 us/iter

byte-and: 0.065379 us/iter

byte-sub: 0.027865 us/iter

1cpy-mod: 0.001143 us/iter

1cpy-and: 0.001100 us/iter

1cpy-sub: 0.001098 us/iter

2cpy-mod: 0.008140 us/iter

2cpy-and: 0.001100 us/iter

2cpy-sub: 0.007711 us/iter

funny-mod: 0.001145 us/iter

funny-and: 0.001101 us/iter

funny-sub: 0.001100 us/iter

where:

`byte` is per-byte copy

`1cpy` is a single-memcpy (assumes message size divides buffer size evenly)

`2cpy` is the split memcpy (which supports other message sizes)

`funny` is single-memcpy with the double-memmapped buffer

and:

`mod` uses `head %= buffer_size`

`and` uses `head &= buffer_size`

`sub` uses `if (head >= buffer_size) head -= buffer_size`

The tl;dr here is that the doubly memmapped buffer performs the same as the 1-memcpy implementation that doesn't do anything funny and significantly better than all 2-memcpy implementations except `and`. Since your page size is gonna be a power of 2 anyway, this means this trick is not really worthwhile and indeed you should just use `and`. But, compared to the other wrapping implementations it does still provide a tangible improvement. That may just come down to how the compiler was able to optimize it, but I don't feel like nitpicking the generated code to figure out why right now.

When I originally wrote this, it indeed was not

Author here. I was 22 when I wrote this nearly 8 years ago. I just thought it was neat, give me a break. Thanks.

What is a "super segment hybrid display"? Looks cool, has VFD vibes, but I assume it's just an OLED with an overlay or something based off in the Verge article "Most of the KO II’s parts are just off-the-shelf components, including the display"

> Like Hysteria, Brutal is designed for environments where the user knows the bandwidth of their connection, as this information is essential for Brutal to work.

They don't quite say that this is a bad idea for use over WAN. If they intentionally avoided ruling out such usage in this qualification, they're making an implicit assumption here that either the last-mile connection or the endpoints themselves are going to be the bottleneck. If some router in between is having a bad day, it would definitely make its day worse.

edit: I wasn't familiar with Hysteria but now that I'm reading those docs, I guess the intent is for this to be used on the internet. In that case, it does seem pretty like it'd be pretty adversarial to run this. I bet if it saw widespread adoption it'd make ISPs pretty upset.

edit 2: Going slightly off-topic now, but I wonder if the bandwidth profile of Hysteria compromises its HTTP/3 masquerade?

Yeah, I agree full DIY is not for everyone, but SMT assembly is pretty affordable even in small batches these days. I just placed an order for 5x of a 60% unibody ortho board and it came out to roughly $40 a piece before switches, case, etc.

Appears to be ok now. The other comment about a move is most likely accurate.

> * A replacement front-end for "ffmpeg", see above

I have one of these too... It's kind of frightening how hard ffmpeg is to use without some kind of custom frontend. I have probably dozens of bash/python scripts to invoke ffmpeg for different common tasks.

- One to extract audio

- One to extract all the individual streams from a container

- A couple different transcoding scripts

- One specifically for gifs

- One to crop video

- A few that I can't remember the purpose of... and can't tell from reading the source

>32 bit color

Terry must be rolling in his grave

Many years ago I was part of a SaaS startup for which local governments were one of our target markets. During our beta we quickly gained interest from the relevant department of the city and were then led on by them for the better part of a year before we went under. This behavior seems consistent with a lot of the comments that have already been posted.

One of the biggest hurdles for us besides the timeline, which I haven't seen mentioned yet, was compliance. The city had a very antiquated security checklist they wanted us to satisfy which was written exclusively for their existing on-prem software deployments in a MS ecosystem, and thus impossible to meet as a SaaS provider. I suspect many smaller municipalities will present you with the same nonsense. In our case, this was not what ultimately killed us, but based on this experience I would advise you to avoid putting all your eggs in one basket and perhaps avoid altogether working a government that is not ready for SaaS once you find out that is the case.