Sesse__

This analysis is just wrong; the Gibbs phenomenon is not some impossible law that you cannot avoid. The Gibbs phenomenon appears only when you have truncated Fourier series; if you drop off more gradually towards the last term (e.g., a cos²- or sinc-scaled dropoff), the phenomenon disappears. Of course, this would be at the cost of a worse mean-squared error, but for most purposes, this is a good tradeoff. If you moved binary stars around, and they indeed had infinitely sharp frequency spectra, surely you would not go for the solution with the most truncation :-)

Last time I was in a California hotel, it had IPv6 just fine. That was 2012. Perhaps you choose the wrong hotels :-)

I don't know what you count as “golden times”, but at least when we started the measurements, there was no indication bot traffic would drive up these stats at all. (You wouldn't trigger it just by fetching a search result page.)

I don't know exactly how they _measure_ since I'm not working in IPv6 in Google anymore, but I know how we _measured_ when we started these stats:

https://research.google/pubs/evaluating-ipv6-adoption-in-the...

This only really holds for small divisors (CPUs since about Haswell or so have had early-outs for them). For large divisors, the inverse multiplications are still faster, even more so if you want to use SIMD.

That works fine as long as nobody actually uses the unhappy path. If major libraries and frameworks do it all the time, you lose. So there is a certain aspect of culture outside what the language itself is capable of doing.

There are certainly hardware implementations of FFTs, in high-speed communications systems and the likes. So it's not just theoretical :-)

You still need at least one IPv4 address somewhere if you want to send ICMP back, yes. (Typically a loopback, i.e., something not connected to a specific interface. Routers use loopback interfaces for rather different purposes than a Linux workstation.) But you don't need to set up an IPv4 address on every interface, so you don't need a linknet plan.

You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.

More like, the point is to facilitate turning off IPv4. It's much nicer to manage a single-stacked backbone, but you still need IPv4 out in the edges somehow (for many cases, anyway). I guess this is another way to do that.

Heck, I would be happy if I could remove some IPv4 linknets from my IS-IS, myself, and just route using IPv6 link-local nexthops…

I wish I knew about this algorithm when I worked in databases; it would be well-suited for window functions (even over floats for most users). Now I think I've seen it described two or three different places :-)

A friend and I bought RAM for our aging servers at eBay in 2024. That was 512GB (16x32GB -- we split it equally) of DDR4 ECC 2133MHz, registered. For… $536.86 plus shipping.

Somehow it feels like we got a pretty good deal, in retrospect. (My server has been since replaced, and I can tell you, 256GB of DDR5 ECC was more than that! There's been a further doubling or two of prices since I bought, though. I think I could maybe sell half the RAM and finance the entire server…)

Alexa was the 39th most popular baby girl name in the US in 2006. It is… not as popular for baby girls now.

> Whether reference counting is a GC algorithm depends on how you define what GC is.

Pretty much all the high-performance GC/refcounting algorithms are hybrids in one form or the other; it's a spectrum of choices. https://dl.acm.org/doi/10.1145/1028976.1028982 explores this in some detail.

> but the point of CVEs is to let you make judgement calls

Realistically, most admins cannot make judgment calls about 1000+ CVEs for a kernel release.

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.