As another data point I'm somewhat stronger, and it comfortably beat me trying to play 'normal' chess against it, at least over a couple of games - though I should have had a draw in one game. I think you had the right idea with trying to horizon it. 11. .. h6?? is amusing.

Kind of interesting too because trying to get into a tactical mess is the last thing you'd ever want to do with a normal computer, even one from the 90s. I assumed it'd screw up quiet positions, but that assumption was quite wrong!

Oddly enough playing against this feels way more 'human' than a depth limited computer normally feels. Not sure what the difference is. I'd love to replicate this setup for practice.

if you've read Kasparov's book he talks about that. He had Deep Blue dead to rights because he found a line it couldn't predict, at least as he tells it. They patched the system between matches, which he considered unsporting.

Yeah aside from being from a totally different rating pool, chess engine ELOs are based on faster time controls or imbalanced openings and don't really translate well to classical chess playing strength in FIDE ratings.

The author caveats things near the end by giving the disclaimer about computer ratings but still goes too far in downplaying the difference IMO.

Am I reading the lichess analysis correctly that you won on time and the game ended with about a +5.1 advantage for White? (displayed as +3.4 on the site)

Yes but the engine you play on the webpage runs at 1-2 seconds per move, not the full 6 minutes per move that would play in a classical game.

If you were set to revenge Kasparov, getting a winning position with ...h6?! Nxe6 must have been particularly sweet.

Many years ago, "8088 Domination" demonstrated full motion video on the original 1981 IBM personal computer:

https://trixter.oldskool.org/2014/06/19/8088-domination-post...

As it turns out, the video was encoded in such a way that it could be played back using the display bandwidth of the original PC, BUT doing that encoding required a modern computer to perform in a reasonable amount of time.

Tangential to the tangent, but turbo codes/LDPC are algorithms for transmitting data over unreliable links with optimal redundancy for a target error rate. They underlie much of modern wireless data transfer, and were known to be possible since Shannon, but nobody had figured out how to actually do it in practise. When they were invented in the '90s everybody reacted with disbelief at first!

I wonder where you'd hit the performance limits vs the algorithmic improvements. On our family pentium 120 playing an mp3 in Winamp took 10-15% of the CPU, so I'm not sure how much headroom there'd be.

But anecdotally I'll share that one of my brother's college roomies was a consultant for RealVideo and was behind their initial codecs. He came back to them with algorithmic improvements a bit later and they just cold shouldered him saying the existing codec was good enough.

So who knows if the biz side folks at the time would have even seen value in better codecs, as unbelievable as that seems to us now in the streaming and zoom call world.

We had video conferencing on a single BRI (128k) with g728 and h264. It was CIF resolution so yes it is possible. And with that loss free ISDN connection the experience wasn't actually that bad. Though this was in the early 2010s where there was still a surprisingly large amount of ISDN around

> Granted, I'm not sure there existed a computer in the 90s that was powerful enough to encode or decode it.

In software, quite possibly not[0].

But I'm sure we could have built hardware decoders that were up to decoding AV1 or HEVC back in the 90s no problem, had those codecs existed at the time.

[0] Somewhat later than the timeframe we're talking about, but I remember with pain the moment I realised my 600MHz Athlon, with 256MB RAM and 32MB GeForce 256 video card, was thoroughly obsolete because it couldn't decode and play the original Half Life 2 preview without stuttering, screen tearing and, indeed, crashing.

When meta released their EnCodec neural net audio compression codec I thought about how the 48khz stereo examples, compressed down to 6 kbps, sounded better than I remember streaming Internet Radio sounded like circa 2003, and would have been able to be streamed realtime, no buffering, on a 14.4 kbps dial up modem (what I was rocking at the time) with a bit of bandwidth to spare for browsin' teh warez sites and .... based on some napkin calcs and assuming a little MMX instruction magic I think completely possible to run the neural net decoder fully real-time on a period-correct AMD Athlon XP 2500+ Barton (overclocked to a 3200+ of course, as all did!).

Man that would have felt like magic...

I'm having trouble finding it but there was an article a while back comparing mp3 speed gains from hardware and software. The hardware was getting better at the pace of Moore's law but the (de)compression speeds for mp3s were far outpacing it, showing that mp3 decoding optimizations were giving orders of magnitude more speedup.

I think this is a common trend for algorithms that are in wide use, where you have Moore's law like behavior on the hardware side and then also software optimizations that give their own order of magnitude speedups.

Fairlight made an Amiga demo called "242" in 1993 which featured a few minutes of "full motion video" on a single floppy disk.

It was heavily compressed, monochrome, low frame rate, but used a clever upscaling algorithm on the frames to make it watchable.

https://youtu.be/wAJx5Ud0pLc

Though perhaps doing it on the Amiga is cheating. It was overpowered for its time.

h264 was used in a homebrew port of Dragons Lair for the Nintendo 64: https://www.youtube.com/watch?v=i89f_CMn7bw

You can technically have some then-contemporary FMV titles run on N64 with a 64MB cart. The hardware lends itself to it because it has the RSP, a secondary MIPS processor with re-programmable microcode. But the best video compression we had at the time was MPEG-2, which just wouldn't cut it.

I remember that Nickelodeon had a contest where the winner was given a videophone and was part of some gameshow. I suspect it ran on ISDN.

Edit: There was also video CD, but that was higher bandwidth than ISDN. I also used to download South Park episodes over my dialup modem. They weren't quite real time (IE, it took longer than the playback time to download,) but they were a low multiple. (IE, a 20 minute episode took ~30-40 minutes to download).

I've seen this in reality - compare the sound of an XM radio from 2003 to a modern one, same codec, same symbol rate, better audio quality. The same is true on digital two way radio (DMR, P25, TETRA, etc) the quality has improved because we can make the codecs do more intensive work, because the hardware is faster.

Wouldn’t you still need the CPU horsepower to decode it?

Well, those modern codecs also take a lot more compute and memory to both decode and encode..

h.264 is shockingly clever when you get into the nitty gritty. The core transform is a bit like a jpeg frequency transform, but is designed to run entirely in 16 bit integer maths and on 4x4 blocks. Ergo, it would run on MMX.

So, in short, probably. Particularly if you could get a hardware accelerated surface that transformed YUV into RGB.

Bill Joy once said in an interview that if you look at scientific computing it wasn't just hardware that advanced at a consistent rate, software also consistently made large speed gains over time.

I am about 300 points higher and think this is roughly correct. In openings amateurs will actually analyze more since GMs just have hundreds of opening lines memorized many moves deep. Middlegame and endgame there're usually just 1-3 reasonable plans that are obvious to a GM (but not at all obvious to amateurs) with 1-3 initial moves each. So, again, probably about as many as I consider.

The only time when GM will definitely analyze more lines than an amateur is in a highly tactical position but that happens, again, maybe 1-3 times per typical game (tactics themselves will last several moves, but they would be largely calculated through at the beginning of the tactical melee).

Human brain can do calculations in the back of their head without realizing it. Verbalizing does not mean it's all they thought about.

Ya that's definitely a simplifying lie.

It's totally true that most people overestimate how much of GM's abilities comes from pure calculation, and underrate intuition. That's what it's getting at.

But in classical games GMs are, in fact, doing tons of calculation, and the statement is literally completely false.

I'm not sure. I'm not into chess but I've watched other strategy games; I'm fairly confident streamers are vocalizing a lot more than they would actually be consciously considering if they weren't streaming.

Back in the day I remember Jon Finkel (a legendary Magic: the Gathering pro) saying* you're supposed to "focus only on what matters."

It stuck with me because I think it's genuinely what they do, but also seems like completely useless advice. I don't know what matters! That's what makes you a pro and me not.

* Wasn't sure if my memory was correct. A web search finds a Mike Flores article citing Zvi calling this Finkel's Law.

I agree. Everyone should check out this famous post-match interview with a strong GM, where's he's simply asked "Can you tell us about the game?" and talks for 13 minutes straight (with no board to reference) about all of the lines he calculated: https://www.youtube.com/watch?v=pUgvAoTzWBA

Notable because he departs from the book opening early on and has to find some brilliant moves to keep himself out of trouble. The breadth and depth of his calculations seem beyond what even strong amateurs consider, more than just choosing better lines to analyze.

There's an analog in machine chess. According to the research paper from 2017, AlphaZero considered ~10,000 moves per decision, 1,000x fewer than Stockfish at the time. h2h it beat Stockfish pretty badly.

>the average chess grandmaster during a classical game will analyze roughly the same number of moves as an amateur player, but they analyze only the most critical moves

What does this mean exactly? They analyze the same number but the grandmaster analyzes "only the most critical moves."

So does that mean at every given analysis opportunity (each move I guess), they analyze better candidates?

If so I guess these 2 things are totally redundant? "they analyze only the most critical moves and do a better job with that analysis."

Alternatively I wondered if perhaps they actually perform analysis on less moves (perhaps because they already know the lines or remember their previous analysis). But I think that contradicts the claim that they analyze about the same number of moves.

My rating is negative 1900. I was always bad at chess and never really gave it a chance tbh. I always wondered though where does the pattern matching stop and strategy starts or it's one and the same?

It makes sense. The space of moves is a tree. If you're doing a breadth-first search and a grandmaster is doing a more depth-oriented search with heuristics for pruning low value branches, then the same total number of moves could be considered, but the grandmaster is reaching the better moves before you.

Hikaru does this as a streaming hook.

Right, but the GMs you see online are often "super GMs". They are on a category of their own in the ultra tail.

an amateur player --> shouldn't an amateur player have an average ELO, i.e. be nearly as bad as me, who never wins at chess when someone even knows their ELO or is a bot above lowest difficulty level.

Yeah I would like to see where that factoid comes from. Maybe it means they explore as many branches from the root position as an amateur, but they explore each branch way deeper and more accurately

GMs also have access to a greater number of memorized situations. Regardless of whether they are conscious of it or not, they have previously analyzed so many moves that they can cut off branches they just know instinctively to be dead ends. Machines could do this, directly reference a massive dataset of precomputed board positions, but that isn't considered a proper chess engine... despite the fact that human GMs do use such techniques.

Yes at that time Intel invented the market segmentation between "Pentium" for "consumers" and "Pentium Pro" for big spenders, and to make Pentium Pro more attractive they removed memory errors detection from the "Pentium" chipsets, which is the origin of the current state, when most non-server computers are very vulnerable to memory corruption and nobody can calculate how much money was lost by most computer owners during the last 3 decades, due to the greed of the Intel marketing, because nobody knows how many of the computer crashes or data loss cases that were typically attributed to unknown software bugs were actually caused by memory corruption.

Because this move was a money maker for all involved, all memory producers and also AMD followed immediately the Intel initiative. Memory modules without ECC would have never existed if adequate consumer protection laws had existed.

Yeah, the Pro and MMX were totally different market segments, not alternatives for each other. The Pro's competition at the time was DEC Alpha, PA RISC, etc. It wasn't a chip that made sense for ordinary PC users at the time.

Just one caveat: the Pro overlapped in time with people running a lot of 16-bit code, and I think the Pentium MMX was faster for that, or at least that the Pro didn't offer much edge.

Pentium Pro did out-of-order execution, Pentium MMX did not.

“In principle, I could have used the same engine itself as the teacher, but just to save on wall clock time I used Stockfish. This reduced the wall-clock time from ~4000 1996-core-years (something entirely doable in 1996---but sadly not something I can do with my single lonely desktop) to just a few days on a modern desktop running a modern engine.”

I see no reason to doubt the author here.

Actually, even pre-NNUE Stockfish wouldn't be an entirely fair comparison, because all hand-coded pre-NNUE heuristics was tested using Fishtest [0][1] - a distributed testing framework with compute, donated by volunteers.

And I think that Fishtest is actually what made Stockfish the strongest, because no other engine's performance ever was evaluated on such scale before.

Stockfish was the first to use hard data instead of vibes, when selecting algorithms and heuristics.

So, even if we add a rule that NNUE is not allowed, because it was trained on modern GPUs that, obviously, didn't exist back in 1996, hand-coded heuristics would also take a ton of compute to develop.

Bitter lesson strikes again, even when you don't expect it.

[0] https://en.wikipedia.org/wiki/Stockfish_(chess)#Fishtest

[1] https://github.com/official-stockfish/fishtest/wiki

Yes, but the implication is about 'hardware overhangs'. It is colossally expensive in compute to develop the full history of Stockfish and NNUE and train the final SOTA checkpoints... But once you do, you can run it on even the tiny dumb chips like 'every smartphone' to get human-level chess performance on billions of nodes overnight. (Application to other domains of more real-world relevance than 'playing chess' left as an exercise for the reader.)

NNUE was added to Stockfish in 2020. Although this was a big improvement, it was already extremely strong before that. With plain hold hand-coded logic as a board evaluation function.

Stash has never adopted NNUE and breaks 3k with ease

It's also great reference engine with all of the pinned tags of its evolution.

https://github.com/mhouppin/stash-bot

https://chessprogramming.org/Automated_Tuning has excellent history. Still substantial compute on tuning, but viable.

You could have used one or more Deep Blue computers as the teacher model, or just a cluster of regular PCs doing very deep searches.

Doesn't the author address this point? They speculate that it could be attained through self play back then using a ton of 1996 compute and time, but it's theoretically possible.

No way. The parameter count can't fit on consumer devices, and you're not getting orders of magnitude smarter behavior with smaller models.

Why? It's late 2026, everyone is using LLMs to write code in some shape or form. The author is talking about code, not the blog post.

Who cares? It simply doesn't matter. The author stands behind the work.

I've built engines from scratch. I don't think that would work at all. It's a whole extra challenge to make an engine feel like a human. The engine has to come up with its best move and then sometimes choose not to play it and play something else for some reason. There are statistical patterns to how humans make mistakes based on their level, what kinds of mistake, how big and how often. Cheat detection is less about knowing the engine and more about statistics.

Maybe a pure neural net (no tree search at all) would stand a better chance. Shockingly, those can play at IM level.

Sargon II is available:

https://c64online.com/c64-games/sargon-ii-de/

My guess is that they would be even easier to detect.

From what I gather cheat detection uses a combination of factors to determine how "human-like" an account is: time usage, webpage interactions, move quality under time pressure and so on. I think you could probably try to deliberately deceive a specific website's cheat detection with software that tries to emulate how humans play, at which point you'd be in the classic attack vs. defense arms race.

Also notice that for events like Title Tuesday you must play on a dedicated client with at least 2 cameras, so it would be significantly harder to pull it off.

> But yes, totally unsurprising that a megahertz machine with 100MB+ available ram has >2500 ELO.

I think this is underselling it a bit. If you'd told this to the IBM engineers at the time I think they would have taken great interest in how the performance was achieved.

I grew up with these machines around, and as a kid they seemed to so much more powerful than humans. It's kinda weird to think that I became 'smarter' than them eventually. I suspect they will be able to run superhuman AI one day too.

Except it has 64MB of RAM... Anyway, in the early 2000s machines were already doing better than DeepBlue, so it didn't last long

I agree. It is hard to make a separation between what is possible thanks to programming vs hardware. It is only easy to analyze post factum that certain ideas worked. Maybe there are also other factors that are important - time, availability of hardware, knowledge dissemination. What would be possible if the hardware stopped improving.

The lesson isn't always so bitter, after all.

What you've described is true for every metrics-based sport, including running, high-jumping, etc.

What happens in training doesn't count.

It also makes me wonder how the performance compares to a DEC Alpha EV5 from the same year, which was 64 bit and had better FP performance.

> Could a modern chess engine run on a Cray 1? 386? 68k?

Someone built Stockfish for the Pentium (586), 486 and 386 a while ago: https://talkchess.com/forum3/viewtopic.php?t=63857

I don't think there's a meaningful difference between the Pentium and the 80386 except speed. You might have to change the compiler options a bit.

And, with more work, that's true of computers in general; they can all do the same computations once you somehow wire up enough memory: https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Even without an explicit DB it would have been quite strong, core Stockfish would be enough to beat any human as well. Ofc learnings from strange games would still be compressed somewhere in the eval functions.

A modern chess engine plays at like 900 elo above Magnus Carlsen? Why is there any doubt it would beat Kasparov

Engines do not use game databases.

At some point comparing human chess to algorithms stopped making any sense. So there is no realistic pool of games between AI and humans. We would lose every game and vs AI a human ELO would go to 0 (not sure if that is technically possible). It is like this for probably 15 years.

ELO is like probability. A 100 ELO difference is something like 2x odds of winning a game and over a lot of tries it tends to be quite accurate. That was also an argument from Magnus Carlsen that to compare human ELO you need a lot of games and he didn't want to take part in classical world championship quoting this reason (among others).

There's no way to know. It's impossible for anyone to imagine the AI state of the art in 2056.

But it's a fair bet that any kind of RSI will improve efficiency, possibly by a lot. And it's also very possible that 2056 AI will be running on some other substrate - maybe photonics, or something even more exotic - that wouldn't map cleanly to 2026 hardware.

Unlike chess, AI isn't a constrained problem, so there is no single higher ELO metric that would make performance comparable.

Computing in general has always become smaller, cheaper, faster, more portable, more energy efficient, and more connected.

So there may not even be a concept of discrete computing devices in 2056. Or of discrete software and services. Compute may be everywhere, in everything, all networked, reinventing itself continually.

Just because a game could graphically have been displayed on an N64 doesn’t mean the game could be built. Vampire Survivors has hundreds of units on screen at a time firing hundreds of projectiles and weapon effects; running those on a memory bandwidth-constrained 93MHz single core processor in 4MB of RAM would be, uh… a challenge.

> We have this massive hits like balatro, vampire survivors, that easily could be made in the era of SNES or N64. But somehow we have to wait 30 years to get them.

> It clearly wasn't technical side of things that prevented that, but also I don't believe it was lack of creativity.

I don't know those specific games, but I think this often happens because, although the thing has been technically possible for decades, it used to be relatively difficult/expensive/obscure, and now it's far more accessible.

In those days, writing and publishing a SNES game was something that relatively very few people would have even thought to attempt, let alone had the knowledge and skills and capital to pull off successfully. Nowadays, creating and publishing a SNES-level game is comparatively very easy (at the technical level, that is; making a good original game is of course still hard), and so a large portion of the people with an idea and some motivation can actually go ahead and do it. And now that games are fully mainstream, there will be more of those people in the first place. Many of the resulting games won't be very interesting, but collectively we're exploring the design space much more quickly.

edit: I was probably silly to focus on literal SNES games instead of 'SNES era' games, but the point still stands: creating games for any platform back then was harder and more obscure than it is now (especially given that we're talking about a technical level that required quite efficient use of the hardware back then, but can be done with extremely inefficient use of the hardware now).

Better machines make it so much easier to experiment. You could make things fast on a SNES or a N64 but you'd have to sweat for it and your code turned into write-only concrete. You don't have to sweat much anymore and your code can easily stay lithe.

Technology is a progression where we learn new things, built on old things.

Game design (like other creative expressions) is the same. Each new game doesn't come from a vacuum, it's a progression from everything that has come before.

More opportunity to write games. It is infitenly easier to get into writing games now than back then.

Also, don't underestimate the "juice" that these days is relatively easy to do but would be expenseive back then. Balatro has dozens of very small things going on graphically that make it feel real nice to play that most certainly not be free on SNES hardware.

And like vampire survivors is just Robotron/Smash TV with infinity number of sprites on screen. The limitation is very much hardware in that case.

I think it's better to say that it wasn't the electronic side of things that prevented that. Game design is technical.

Every board game could have been built thousands of years ago, at least after the dawn of some reasonable writing/drawing media. But technology in design hadn't accumulated enough. To go farther, every bit of math could have been done thousands of years ago, but new math had to draw on earlier math. New math didn't rely (much) on special paper.

Also, "hit" probably isn't a good metric. Those games might have showed up back then and just been moderately notable, like dozens or hundreds of other games were.

The N64 was extremely constrained by its cartridges. If it had a CD-ROM drive, it could have easily won the console wars of its generation, or at least would have gotten ports of many more PS1 games. Probably one of the biggest blunders in gaming business history. Ah well.

Run some current and still-compiled-for-i686 Linux or *BSD distros on it. See what breaks, save logs & report issues upstream.

A lot of support for old CPUs & platforms they're on goes through emulators like QEMU. Or plain old 'go with specs, disturb code as little as possible, and assume (hope) it still works'. But nothing beats running on actual hardware. Uncommon configurations, specific drivers that may have been broken (sometimes for a looong time before someone notices), spec says A but hardware does B, etc.

Why would it be better for an engine to use less than the maximum time it has available per move?

That's off by an order of magnitude.

200Mhz PPro can theoretically execute 600 MIPS (3 instructions per clock), assuming only high-throughput instructions are used and no cache misses. (the average IPC for realistic workloads is ~1.0 though)

The Pentium Pro is an out-of-order, superscalar processor (that started the lineage of modern x86 processors).

"Bollocks" feels like a very uncharitable read. Sure, investing time/money into creating a better chess engine instead of building a faster computer would not have worked out for IBM, but the post never argues that they should have done that. It makes the point that the majority of improvements of chess engines since have been algorithmic and not "free" gains from faster CPUs.

Deep Blue is just used as a point of reference to illustrate that fact.