Sesse__

GEQO is not to get a better plan than the traditional optimizer, it is to be able to get a plan at all when the query is large. And it's widely known for creating poor plans.

There are papers and Postgres projects that attempt this kind of learning-based optimization, with some success. None are in widespread use. (One part, but certainly not the entirety, of the problem is that it's not just A/B, it's an exponential number of options that all could seem close to each other.)

If you have formulas that actually match reality, what do you need the LLM for? An optimizer is perfectly capable of finding the optimal plan if it has a perfect estimator. In fact, if you could only estimate the number of rows in each subplan perfectly, you have as good as solved the problem already.

This immediately halves your throughput.

The immediate problem: How do you know which one is better without running them?

“Phoronix, but high quality” would also be great.

People kept asking if they could pay for AnandTech, and they said “we'll think about it” for years until they shut down instead because it was financially unsustainable.

Still, we're talking orders of magnitude here. I've fed Shazam with a stream of the cheapest lapel microphone you could get, mounted behind a rack filled with twelve very noisy servers, in a hall filled with 5000 people also all being noisy, and it would reliably recognize music from the other side of that hall before I could do so myself (I had to walk halfway there to hear “oh, yes, it's actually right”). And that's on a stream encoded with 9600bps GSM compression. With Merlin, I can hold out my phone on a silent day, hear the bird loud and clear and it will hardly register.

Shazam primarily identifies on the geometry of spectogram peaks, FWIW (I wrote my master's thesis on the DSP of music recognition back in the day; it's possible that they are doing something more fancy now, of course, but I'm not sure if they would want to). I don't know exactly what Merlin is doing.

For me, mostly a lot of false negatives. I have a Pixel 8, and I have no problems using the microphone normally, but somehow, Merlin requires the bird to be within a couple of meters of me and sing for quite a while before Merlin will even say “hearing a bird”. And of course, you have to be dead silent; if anyone talks or coughs, it will mess up the spectogram badly.

Given that it's colloquially “Shazam for birds” and Shazam is just amazingly resistant to noise, it's a bit disappointing :-)

For any complex system, there's never one single trick or design choice that makes it fast. It's always a large amount of engineering (or exaggerations, of course).

> Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are.

Vibe-decomped projects are also… a different result.

A matching hand-decompile is useful in itself, but it also serves as a proxy for how well you understand the project; how good are the function and variable names, are the structures good, do you understand the entire flow. There are plenty of LLM-decompiles out there that just match but still every variable name is “unk14”, where every flow is total spaghetti instead of going back to something closer to what a human would have written, or even tons of __asm__ statements. The match stopped being a high-quality proxy metric for the quality of the project as a whole. (There are also LLM-assisted decompiles that are high-quality, but then usually with significant human input. And of course, you can try to ask the agent to clean up the resulting mess after you're done matching, assuming you have any tokens left.)

Of course, if you just want the binary back and collect Internet points, you don't care about any of this. But decompilation projects are often made for either a) understanding the game better (for speedruns, TASes, or just general explanation), or b) modifying it. And for both, it is much nicer to have source that is closer to the original.

Yes. Especially when there are common libraries and you can reuse their names, structures or even entire decompiled routines.

There's a fair amount of folklore going around, but less direct sharing than would be ideal.

> Historically there was a notion of "clean room" reimplementation

These projects start off with the original assembly code and use it actively throughout all stages. This is about as far away from clean room as you get.

> I think he's saying that building a browser is not a transferrable skill, like making a generic web page is. Employers don't like specialists.

I recently switched roles, and among the seven places I interviewed, none of them seemed to see my then-current browser job as a problem, even though they were not related to browsers. (The closest one was a company implementing a HTTP reverse proxy, and I did not work on the browser's HTTP stack.)

> I wonder if any equipment ever actually used those other flags for anything?

MiniDisc did. You could make one (digital) copy but not two.

MP3 decoders have, thankfully, gotten faster since the 90s. But yes, a 66MHz is pushing it indeed.

Yes. Which matters a lot when you cannot just update OS kernels willy-nilly (most people did not have Internet connectivity, Windows Update did not exist before Windows 98).

Generally most forms of PGO does not try to capture number of mispredicted branches (which isn't the same as how often a branch is taken).

I once got that question, started with the keyboard switches and the interrupts, and the interviewer sighed and asked me to get to the stuff in the browser.

The demoscene still exists, although it doesn't seem to attain a lot of new members, and most (not all!) of the activity is back on oldschool platforms like Amiga or similar. See e.g. https://www.pouet.net/; Assembly 2026 is this weekend, so there's likely to be new interesting releases coming out.

No, not really. Highway generates rather bad code as soon as you step outside a pretty narrow vertically-oriented scope, in my experience.

GF2P8AFFINE has entered the chat.

(I've both played bridge actively and written SIMD code professionally, bridge rules are way simpler. Actually playing good bridge is probably harder.)

You may be interested in OpenMP.

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).