Sesse__

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?

Android uses one uid per app.

There's no way around it: a non-IPng-having node will have to go through a translation box of some kind.

Yes. Note that it doesn't need to be someone else's relay; anyone with IPv4 connectivity could easily route 2002::/16 into IPv4-land (without having to announce it in BGP for others to use). You could even announce 2002:aabb:ccdd::/48 as a more-specific in BGP if you wanted, although this was more exotic.

Actually, we tried that

I'm always fascinated by how many people think IPv6 adoption would have gone lightning-fast if we just used This One Weird Trick, where said trick has actually been tried and didn't help. They usually refuse to back down even after you tell them so.

The current design was implementable by zillions of cheap humans running cheap hardware.

Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.

I was at a talk where he brought up exactly this (I also once did a talk alongside him, but that's a different story). He said there would be two changes:

1. It would have 128-bit addresses. 2. It would have end-to-end encryption (or was it authentication, I forget).

IPv6 was supposed to fix both of these, with IPsec mandatory, but the latter demand sort of faded out into obscurity. We ended up basically solving encryption by pushing everything into TLS anyway, which I guess solved much of the same problems although at a very different layer.

So, in your example, each request needs 0.1 core-seconds of PoW. Is that right? Or, since you're saying 10000 hashes across the entire machine and 1000 needed, then on a typical 96-core server you need 9.6 core-seconds of PoW? The former means you pay about $0.0000005 per request at standard cloud rates; the latter means you pay about $0.00005 per request _and_ your site is totally unusable by legitimate clients. Both are _easily_ worth it for someone backed by VC billions and hungry for data. The network and storage fees are likely to be more significant than that already, not to mention actually training a model; they don't balk at downloading terabytes of crap already.

Note that none of this assumes any sort of acceleration from parallelization (be it through GPUs or reusing work across servers) or precomputation relative to what a normal client does. Compute is just really cheap in dollars compared to the cost of having a user wait, and these companies _also_ have a lot of appetite for spending dollars compared to that of a normal user. As others have pointed out, the only reason why Anubis works (sort-of; not for everyone) right now is that it is uncommon enough, essentially “proof that you bothered to have your crawler run JavaScript at all”. It's a confusion measure.

Proof of work does not work.

I don't have a book, but my best recommendation would be: Learn how to measure. Whatever language you are using should have a profiler. Learn how to use it and look at how your code holds up. Look for surprises; those are optimization opportunities and learning opportunities. Make a change that you think has a reasonable shot at optimizing performance, look at how the profile and benchmarks change. If you're using a compiled language, look at what the generated code looks like. Is it what you'd expect, or did the compiler do something that blindsided you? Can you get rid of that overhead? Can you use a faster algorithm? Can you make things faster without making it an unmaintainable mess?

In general, you must expect to try ten things and then one of them will help you; fewer if your ideas are bad. :-) Occasionally, you learn new things (either about your machine or your language or your code base) and then you can try that elsewhere in the code (but don't go overboard, every technique has its limits).

DO NOT FALL PREY TO SUPERSTITION. Always measure in one way or the other. Don't do stuff blindly just because someone on the Internet told you (there's a _lot_ of bad performance advice out there).

This is called “installing a cryptominer on your web page” and is generally considered illegitimate.

That's a completely different question, your claim was about parallelism.

Uh, is it resistant to parallelization across multiple sites? Because that's the situation for the scrapers. They're not trying to solve a single PoW challenge across many cores.

The sad part is that most employers don't care particularly about performance optimization skills (the economics don't work out, they can often just fix the problem cheaper with more hardware—and even if they can't, they mostly don't bear the cost themselves).

The fun part is that when your employer _does_ care about software optimization, few people are actually good at it and your skills are more exclusive :-)

I once measured a 80s-communally-built event space with a laser meter (it was useful to have digital floor maps for event planning). No measurement was a perfectly round number. No angle was perfectly right. Nothing really lined up. Except… there was this one set of stairs leading up to the stage. It was perfect. Every step was exactly the same in all dimensions, to the millimeter. It was perfectly level. I always wondered who this stair craftsman was, who prided themselves on doing such professional work among the presumed chaos. :-)

Also to your point, this is why compliant peak meters use a mandatory 4x upsampling at 48k.

This isn't due to latency, it's because the true peak (in the analog waveform) could be between samples.

It's behind a flag, if you want to play with it. (The easiest way is usually just to test in Canary.)

Did you actually test? I did it and it worked fine (and zooming in confirmed that the RGB bars are nicely preserved). Be sure to put your subsampling at 4:4:4.

Why do you think it wouldn't work for a JPEG? I just made one like that, and it worked just fine.

Just remove the A record, and nearly all the scrapers disappear. :-) (And then you get one email per month or so that “your host does not resolve in DNS”.)

Are you maybe confusing “downstream” with “mainstream”? Being “downstream” of a product means that you are a derivative of that product (your upstream), taking in basically all of their code and adding your own on top.

And while they've recently announced more of this stuff will move to FOSS soon, at the same time their response rate to new bug reports has become worse than ever before, which is deeply worrying.

A huge chunk[1] of the MySQL developers were laid off (and also large amounts of QA etc.), so it's not surpising at all that they are struggling to keep the lights on. There are talks about an external group trying to form to take more ownership, but so far, your best bets are MariaDB or Postgres, depending on whether you think MySQL 5.1 was the epitome of relational databases or not.

[1] From what I gather, about 75%. In the first wave.

MySQL has never been downstream of MariaDB.

They are using a fork, although nobody _really_ knows how up-to-date it is.

It's the one that nags you to upload all your IMAP passwords and email to Microsoft's cloud.

FFmpeg has its own native H.264, HEVC, MP3, Speex and AAC decoders. It's true that they don't have an H.264 or HEVC _encoder_ without calling out to external libraries, but they have a pretty good AAC encoder now, and TBH most use of FFmpeg is for decoding, not encoding.

due to FFmpeg back then lacking any framework for code sharing between components and codecs

Funny, I remember this being completely different; FFmpeg bundled ffserver, which transcoded to a bunch of codecs at the same time (sharing motion search and everything) precisely to demonstrate how similar the codecs were and how much could be shared. (Of course, that could easily be spaghetti, but not spaghetti for non-code-sharing reasons.) All on the 400MHz-class machines we had at the time. Do I remember wrong? I haven't looked at these old releases in forever.

The idea of having two arguments to fread() is presumably to be able to do something else than all-or-nothing when there's a short read.

ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines.

FFmpeg doesn't do “pipelines”. It's a library, not a framework.

It's a signal. It's not a strong signal, and you certainly should not base your entire perf on it, but if the number is unusually high or low, it's a signal that could warrant further investigation.

(I once worked with an engineer that had two PRs, both fairly small bug fixes, in a given calendar year, and when I looked more carefully, they did not have any other obvious output or impact.)

Also, performance is generally pretty low; I've been on projects where we rewrote OpenCV code into more-or-less obvious hand-rolled code and won 5x perf. The abstractions are generally a bit too thick and oriented around single pixels (which also makes the API a bit too verbose for my taste).

Useful, then, that you can start several vectorized floating-point muls each cycle. (E.g., most modern x86 are 3/0.5 cycles for vmulps. No 20 cycles in sight.)