Sesse__

So, you basically want an economist to be President? Not unreasonable, and certainly not unheard of. At least the pool of candidates is pretty large.

I've used LZO as a spam classifier on chat. Spam tends to be very content-less and repetitive...

Match-finding does not need to be quadratic. However, truly optimal gzip block splitting is very slow, indeed.

You're probably thinking of https://github.com/simonlindholm/decomp-permuter, which is used across many more decomp projects (and can do a lot more than swap lines). It's a huge help, but it's by no means enough for all regalloc differences; there's lots of stuff it cannot do.

https://decomp.dev/ is probably (roughly) what you're looking for.

> It’s AOT dynamic recompilation and the original IP isn’t distributed.

The Git repository contains tens of thousands of lines of assembler code that seem to come from the original.

They are designed by different teams and have different ways of doing math. You could just as easily say “why are the efficiency cores wasting an extra cycle for each multiplication doing fixups of an uncommon case”.

Fabian Giesen explains in more detail here: https://mastodon.gamedev.place/@rygorous/117277063419144390

> For example, one could analyze _actual_ distributions or whatever (instead of assuming uniform)

Postgres keeps histograms (including N most common values) for all columns; it does not blindly assume uniform distributions. (Presumably an LLM would have access to the same histograms.)

I think calling GEQO generative is a bit of a stretch; it's just a different way of searching through the same space with the same cost model. More or less devolving to “let's take a bunch of randomized join orders and see which one is best” :-)

And yes, large joins is definitely for OLAP use. If you have 20-way joins for OLTP, you're either crazy or you're using an ORM.

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