I thought about something the other day... Modern chess sites run proprietary algorithms to detect cheating by modern engines. But would it be possible for an old engine, let's say from the 70s or 80s, running on modern hardware to deceive these algorithms?
They wouldn't win every tournament but still have a respectable performance.
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.
Yes, along side you robosexuals
Wow how are things down in imagination land.
Maybe a pure neural net (no tree search at all) would stand a better chance. Shockingly, those can play at IM level.
Biology had a lot of time, attempts and pressure to make this work but even the most optimized lines (something like a magpie) need more complexity (almost a billion neurons) to get a fraction of superhuman intelligence.
Results with small artificial neural nets are very limited so far, too.
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 had a Pentium Pro 200 back in the day, to run 3DSMax 1.0 on Windows NT 3.5.
Unfortunately, most humans see big|new|expensive hardware as great status signifiers, barriers to lesser folks joining the Cool Club, and optimal sources of sales commissions.
> 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 and do a better job with that analysis.
I don't buy this. I've seen GMs playing online while verbalizing their thought process (on twitch / youtube videos where they livestream their play), and they consider way more branches than I do, while also going deeper than I ever would on some branches. My top rating in lichess blitz is about 1900, not bad but way lower than a GM.
So if you measure amateurs via club players (=what people might have considered chess amateurs before), that might give you a different result from the average online player (=what people might consider average amateurs today).
It is much easier to imagine the 1600 FIDE OTB player doing 20-40 positional evaluations than the 1200 random chess.com scrub (eg me) doing the same.
This is a known thing among chess players, and even low-skilled players do it to some extent. A newbie to chess can (and almost every teacher will say 'should') work their pattern recognition by just solving tactical chess puzzles and very quickly improve at spotting things like one or two move checkmate patterns or forks or pins or whatever.
It's more of a memory thing than subconscious calculation.
Would you make the move based on vibes alone in a non-blitz game? The calculation is still required and it is faster for those already familiar.
Even a new player handed a rook and king endgame doesn’t need to consider every single square the rook can land on.
Sometimes it really looks like "calculations in the back of your head". Have you ever been struck with a 5 moves long tactics in positions you've never seen? Because I have.
There are hardly any other explanations than subconscious calculation.
[1] (2011) has a summary in the introduction:
de Groot presented chess players of varying skill, including some of the best players of the time, with an unfamiliar position and asked them to think aloud as they analyzed the position and chose what move they would make. de Groot found that, contrary to popular belief, the strongest players did not think further ahead than weaker players. World-class Grandmasters (GMs) searched at a similar depth and considered a similar number of options as mere chess experts.
Six Grandmasters, five International Masters, six Experts, and five Class A players completed the think-aloud procedure for two chess positions. Findings indicate that Grandmasters and International Masters search more quickly than Experts and Class A players, and that both groups today search substantially faster than players in previous studies. The findings, however, support de Groot’s overall conclusions and are consistent with predictions made by pattern recognition models.
Masters (2350+) | Intermediates (1800-2200)
(Mean values only, i tried inlcuding stddev but it was hard to read)
Positions Evaluated (A): 145.3 | 138.6
Positions Evaluated (B): 216.6 | 190.6
---
Max Depth (A): 11.7 | 9.4
Max Depth (B): 14.1 | 12.0
---
Mean Depth (A): 4.1 | 3.3
Mean Depth (B): 4.9 | 4.2
What i found interesting was that the "intermediate" group had a higher number of "base moves" they evaluated (eg Pos A: 5.6 | 8.6).
The previous studies (de Groot and another rperoduction from 1998) had "Nodes visited" for position A at 51.6 | 34.3 and 48.3 | 40.1 so similarly close together as the new ones, but much lower. (depending on your definition on "similarly close together")
[1] https://onlinelibrary.wiley.com/doi/10.1111/j.1551-6709.2011...
I actually don’t know this for sure, I should say that they don’t verbalise more moves than I think about. It’s plausible and perhaps even likely that they have a lot of moves or positions they do touch on but immediately discard so don’t even verbalise.
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).
The main thing commentators here are missing is that GMs have more confidence and do not repeat their analysis, but amateurs (strong club players included) typically re-analyze the same lines over and over. That alone would account for far stronger play with fewer moves considered, if you count the same move multiple times, which you should!
Also, Jonathan Rowson (Scottish GM - peak about 2600) describes his training matches with Mickey Adams (peak #3 or so in world - 2760), and says pretty much the same thing. Most of the time he asked “what about this line I rejected”, the answer was usually “I hadn’t considered that”.
Those critical moments are a big part of the difference between a GM and a good club player though. If a GM was somehow handicapped to not calculate such tactics, I think lesser players would be able to draw games against GMs much more often.
I agree that GMs can avoid calculation in many positions (e.g. openings as you said), but the value of broader and deeper calculation is still huge in chess.
It's not one and the same, but strategy patterns are definitely a thing too.
There are:
- tactical patterns (e.g. "back rank checkmate", or "pair of pieces that can be forked by a pawn");
- strategy patterns (e.g. "knights are good in closed positions", or "in a same-colour bishop endgame, put your pawns on the colour opposite to the bishops").
There's also calculation ability which also partly relies on patterns one has seen before.
1. Take a little extra time to visualize what will happen after you make a move. Will the piece be vulnerable? Does moving that piece leave a different piece vulnerable? I'd argue the biggest beginner mistake is not seeing that their move leaves a different piece vulnerable to being captured.
2. Don't move your queen into the board until after you move both bishops. This simple rule of thumb makes it far less likely you will lose your queen early, and it forces you to do a lot of other useful things (develop your pieces, control a portion of the board, etc).
Disclaimer: I am not good at chess, but when I played semi-regularly these helped me hold my own against other beginners.
Im not sure where the misunderstanding is.
The article says better players calculate a similar amount of moves and your anecdote shows the better player calculating a lot less.
So yeah it rebuts but the idea that GMs analyze more moves but it doesnt agree with the article, right? I guess just in the sense that its not more.
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.
This is intuitive and I guess I'm not surprised this is what was meant. They analyze the same amount of moves they are simply better at it (picking candidates, calculating, etc.)
I guess maybe im being a bit nitpicky but I feel like this is still a misleading way to say that.
> 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 and do a better job with that analysis.
You could just omit "only the most critical moves" instead of listing it as an additional thing.
> the average chess grandmaster during a classical game will analyze roughly the same number of moves as an amateur player, but they do a better job with that analysis.
"only the most critical moves" sounds like less, especially when listed in addition to analyzing better.
I digress.
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.
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.
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.
It's not so easy, a lot of that better programming can be attributed to better hardware, it wouldn't have been possible to implement NNUE or Fishtest without modern hardware.
That's discounting architectural innovations & improvements which are bound to happen somehow.
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
For chess though, there are time constraints. The 386 is a lot slower. Is it fast enough?
An 80386 is about 10–13 Dhrystone MIPS, while a 200MHz Pentium Pro is about 90–450, according to https://netlib.org/performance/html/dhrystone.data.col0.html. So we're talking about a further slowdown on the order of 20×. I don't know how to estimate how much that would lower its Elo.
The article says:
> By making a number of adjustments to the algorithm and tuning it to the Pentium, we can increase its Elo to 2846 ± 35 at 1 second per move, 3109 ± 79 at 10 seconds per move, and 3180 ± 80 at 30 seconds per move.
So making it 30× faster would raise its 1-second Elo by about 334 points, and ln(30) is 3.4, so that's about 100 points per factor of e. ln(10) is 2.3, so we'd interpolate a prediction of 230 points gained at 10× faster, reasonably close to the 263 points reported.
If we extrapolate that in the other direction, ln(20) is 3.0, so on the 80386 we'd expect a loss of about 300 Elo points, down from 2846 to 2550 or so. Still enough to wipe the floor with Crafty, but low enough that Kasparov would usually beat it.
But we don't really know if that extrapolation is valid.
A common rough rule of thumb used throughout the 2010s (because it no longer holds) in computer chess was that a 2x speedup gives about 50 Elo. This mostly holds in that region but at low levels it is more like 100-200 points.
Someone built Stockfish for the Pentium (586), 486 and 386 a while ago: https://talkchess.com/forum3/viewtopic.php?t=63857
Maybe this was satirizing people running after every shiny new thing, but the MMX certainly wasn’t. The Pro was the first P6, a totally new, out-of-order microarchitecture that the Pentium 2 would be based on. The MMX was a standard P5 Pentium with a larger L1 and the MMX vector instruction set which, while the first of its kind in an x86, was ultimately not used much in applications, partly because it was integer-only (also because it awkwardly co-opted the existing FPU registers rather than having its own register file). In any case, the Pros were expensive and meant for business use, while the MMXs were consumer processors.
The launch of Pentium Pro in 1995 was the moment when Intel segmented their CPU line into CPUs for consumers & server/workstation CPUs.
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.
I spent some time trying to figure out how some of the humans seemed to have trapped the machine out of the opening, because it looked like the human was winning.
Throw a 3dfx Voodoo in there and do some real-time 3D Gaussian Splatting!
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.
Back in 2021 I got cfish and weiss working on a 386sx, though didn't test it much. cfish was doing 5k nps so some results can be extrapolated. NNUE complicated things due to RAM requirements. Though I did train a small one for lichess at some point and they can be surprisingly good.
edit. A good view on the continuous progress of Stockfish itself https://nextchessmove.com/dev-builds
I wish disclaimers like that would be at the start and not halfway trough the text.
On a kinda similar note i always wander that about indie video games. 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.
Some could argue that it is just what art is, we will get every year some new thing, creating all "possible and meaningful" art right now isn't even valid thing to consider, because art isn't about exhausting a finite set of possibilities.
But at the other hand some mechanics, design solutions in the hindsight seem kinda obvious and make me wonder, what things we do not see now, but will look obvious to people 30 years from now.
> 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).
I don't know I fully agree with this. Consoles always had the "walled garden" thing going for them, but on the other side of things, developing games became so cheap and easy during the personal computer revolution that whole industry collapsed in '83 under a massive flood of shovelware...
Just cutting the high resolution textures might get you there.
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.
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.
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.
Of course, “human vs supercomputer” is more exciting to the public than “human vs toaster controller”, especially when the latter in small quantities costs less than a cup of coffee.
I just ran Andrej Karpathy's Tiny Stories model on a tiny ESP32. In principle we could probably have done this in the 80's and it would have been so amazing.
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).
Deep Blue is just used as a point of reference to illustrate that fact.
So a computer from back then _can_ run at Elo +3k, but the programmers at the time wouldn't have been able to implement it even if you went back with a time machine and the blueprint for the technique. They wouldn't have the teacher model to distill from.
I see no reason to doubt the author here.
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.
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
I am half remembering a post from more than a decade ago but a process similar to Fishtest was supposedly used for Rybka. But in general I agree.
It would be a tight fit, but I still think within feasibility. We've gotten so good at shrinking video that it kind of feels like wizardry to me. Granted, I'm not sure there existed a computer in the 90s that was powerful enough to encode or decode it.
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.
320x240 is less than 1% the size of 3840x2160
In an alternate universe where HEVC existed in the 90's, conceivably intel could have included hardware to assist in decoding it.
https://holmesrpi.org/Books/NumComp2/WebPages/NumComp/Is%20T...
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.
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.
in action on 16Mhz 286 Packard Bell Victory, fullscreen at 30FPS https://www.youtube.com/watch?v=fEJPLT_rSRY
a) it's a legacy product that operators don't care about anymore.
b) latency is important for voice, but modern voice calls have terrible latency. POTS was digitized (for T1/PRI) with g.711 which provides a 8kHz sample rate and 13 or 14 bit samples encoded down to 8 bit. PRI lines were multiplexed one sample at a time. There's a small amount of algorithmic delay, but not much.
Modern voice calling is packetized, and most systems have packets of at least 20ms, you have more encode/decode time, you probably have a significant sampling buffer, and you may have to wait for network access, so the receiver needs to add a jitter buffer to manage that. Additionally, echo cancelation needs processing time, and it's also harder with longer latency. Some systems use longer packet times to reduce network overhead.
c) codecs: g.711 has a terrible pass band, GSM codec takes the same inputs and compresses it harder. g.722.2 (amr-wideband) is better, but it requires proper call setup and that is problematic for calls from one carrier to another. If you're calling via apps, there's potential for more flexibility, but you likely get whatever the developer thought was good enough.
GSM.. the added comfort noise was weird to me the first time I heard it while roaming.
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.
I was involved in dial-up era 'postage stamp' video streaming. 240 pixels in 256 colors and it felt like visiting the future. Good times :-).
> who knows if the biz side folks at the time would have even seen value in better codecs
As someone who gradually went from code to the biz side, it's pretty likely they did understand it was better (at least at some levels of 'they'). A lot of times, saying "thanks, but what we have is good enough", especially to an outside contractor, isn't a technical or value judgement. It's more of a generic 'not interested right now'.
Consumer streaming as a business didn't really happen on one linear ramp. There was a period in the mid-90s I call 'proto-streaming' where there was a lot of early-adopter excitement and experimentation; but it mostly died out and then got rebooted a few years later. Although Real Networks as company did bridge the two eras, it was rough and they survived on corporate training use cases. The streaming reboot is the ramp that can be roughly traced through to today.
The reason proto-streaming didn't take off wasn't the early codecs, although it's true they weren't good enough yet to succeed. It was that the business models, content supply and distribution infrastructure weren't able to scale yet. So, Real Network's reply may have been the polite shorthand for an internal mtg that was more like a VP ranting "That's great but I got three fires burning the building down right now - and that ain't one of 'em!"
Reed Solomon codes are higher quality but much older and requires a matrix solve (LU decomposition plus yadda yadda, equivalent to inverting a matrix)
Turbo codes / LDPC are IIRC O(n) instead of O(n^2.5) or whatever the matrix turns out to be.
-------
Reed Solomon codes are closer to the Shannon limit but are not scalable, slower than linear and require quadratically or cubically more compute for the data.
Turbo Codes and LDPC do a shittier job but far far faster. So that makes them actually more ideal in practice even if they are worse than Reed Solomon codes.
There's a trick in particular that allows you to rewrite the matmuls as a sequence of vectorized XORs, processing the same number of instruction words as other implementations (give or take control flow) but doing just a stream of zero-data-dependency vectorized math with lots of execution unit support. If you're feeling fancy you can do CSE and also choose the matrix constants minimizing XOR count.
Even without that, just basic AVX2 tricks get you a few GiB/s.
Unless the more expensive matrix math you're referring to is supposed to have n be the size of the code rather than the size of the data?
I think this line says everything about your assumptions.
RAID-6 or other filesystems use extremely small ReedSolomon codes so these caching methods are possible.
But let's say you have a moderately sized (well, moderate for LDPC anyway) 65535-sized Reed Solomon problem (the maximum Reed Solomon that fits in 2^16 bits). Even with just 1% redundancy that's 655 parity.
Now consider the possible errors to solve for: 20 erasures means you have ~65535 choose 20 combinations of matricies to cache.
Or roughly 10^77 matricies you need to pre solve and cache to handle 20 erasures. Aka basically impossible.
----------
Now if you have 40 hard drives and are dealing with 3 or 4 errors tops, well sure caching is good and solves everything.
Reed Solomon is a perfect Maximally Distance code. For small n it's perfect.
For larger or even just moderate N (kilobytes for packets), it's too unwieldy. LDPC and Turbo Codes (which are imperfect codes) fill in the gap and allow for larger sizes as long as you give up on perfection.
Interestingly, for a lot of bit flip probabilities, iterating a smaller code has little additional overhead and better error handling (lower chance of that longer message having an uncorrectable error). With a 10% bit flip chance, even a 253+2 code over GF256 looks attractive comparatively (horrible overall, but better than the proposed larger code; I think your code makes more sense in practical regimes).
Ethernet frames are in the 1500 bytes MTU region. Maybe jumbo frames in the 8000 bytes or so.
Traditionally, "Fire Codes" could provide error correction at high speed over the whole packet (https://en.wikipedia.org/wiki/Burst_error-correcting_code#Fi...), not as well as Reed Solomon (or LDPC/Turbo codes), but that should give you an idea that the 1000 to 8000 bytes of "error corrected data" is actually quite pragmatic in the real world (ie: a lot of Cisco switches or routers that rely upon Fire Codes as forward error correction).
Note: A 32-bit fire code could only protect from errors that exist ALL within a singular 32-bits "burst". Its a "bad" code but very high speed. Fire Codes can never protect against two random errors spread far away, its "purely" a burst error correction scheme.
As we look towards more recent ethernet standards (ex: 802.11), they tend to use LDPC or Turbo Codes instead. I don't know the MTU of 802.11 but I assume its also in the 1000 to 8000 bytes region.
65535-sized is the limits to Parchive, which uses 16-bit Reed Solomon. It doesn't grow quite to that size in practice, but you're still dealing with error correction (or erasure-correction) codes far larger than what happens in RAID6 or other such scenarios.
---------
All are pragmatic. But the region where Turbo Codes / LDPC excels at are the much much larger codes where Reed Solomon's O(n^2.5) (or something) is a disqualification. I'd imagine that if "Pararchive" were rewritten with today's technology, it'd be a Turbo Code or LDPC.
There are soft versions of RS codes, but these came much later and use the same iterative techniques that Turbo/LDPC decoders use.
Reed Solomon codes are literally perfect, or more mathematically they are Maximum Distance Codes (https://en.wikipedia.org/wiki/Singleton_bound)
Turbo Codes and LDPC are provably imperfect, failing this property. However, they are very close to perfect (like 99.999999% perfect in practice).
Now the issue with Reed Solomon is that matrix factorization / effective matrix inverse. It's basically impossible to run Reed Solomon above say, 16 bits or 65536 elements or so (2 bytes at that point so 128kB). Because the matrix to solve this would be 65536 x 65536 x 2 bytes or like 8Gb or something.
Hmmm, I guess modern computers can handle 8GB lol. But you get the gist, the O(n^2) is a problem.
LDPC and Turbo Codes are linear. So a 4MB LDPC is gonna be you know... Actually possible on modern computers... While a 4MB Reed Solomon Code will need some number of exabytes to just build the damn decoding matrix. (32 bits times 4MB squared or something like that)
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.
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 won a copy of Sonic the Hedgehog in that contest! AFAIK, it was just a retail copy and a letter; the game might still be at my parents' house, but I certainly don't have the letter. I was not selected to be on the show or anything. I remember watching the scrolling rules when they were doing the promotion and writing down a couple bits of the address every time.
It was heavily compressed, monochrome, low frame rate, but used a clever upscaling algorithm on the frames to make it watchable.
Though perhaps doing it on the Amiga is cheating. It was overpowered for its time.
So, in short, probably. Particularly if you could get a hardware accelerated surface that transformed YUV into RGB.
Man that would have felt like magic...
>Chess engines like Stockfish, running on silicon instead of our human brains, dominate us at the first of these and analyze millions of positions per second.
the 200MHz Pentium Pro he's talking about was capable of 1.5 million instructions per second, which on it's own is not quite millions, and how many instructions would be required to evaluate a position, let's say very optimistically it's 10 for "valid move", now we're at 150k positions per optimistic second.
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).
Exact same thing happens in chess. Here's a video of Hikaru playing puzzle streak [1]. He's definitely a freak of nature in terms of speed, but all strong players are going to be capable of similar displays, even if to a less extreme degree. You obviously can't do anything remotely like this when you're still consciously thinking about what attacks what.
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.
Also interesting that he bothered to buy the physical hardware rather than just simulating it.
Fabien Letouzey released the Fruit engine in 2004, and within six months, HIARCS had its biggest Elo gain in over a decade. No future engine followed the same slow Elo growth curve after that. Similarly, after Vasik Rajlich released Rybka, it pulled 150 Elo ahead of everyone else on the same hardware. So the history of chess engine development certainly supports the theory that a better evaluator can make an exponentially stronger engine on equivalent hardware.
Yeah sure. Anthropic researcher posts a narrative that Moore's law wasn't required to beat Kasparov on consumer hardware just before the IPO. So the improvement roadmap of Anthropic is justified.
This is the same guy that was shilling the underwhelming Mythos model.
It was trivial for me an expert-ish player (1950 USCF 2300+ bullet) to find a line to beat it. https://nicholas.carlini.com/writing/2026/algorithmic-improv...
Also 3000 engine elo is not really a good direct comparison, engine elos are kinda meaningless when comparing human to engines, they are meant to compare engines to engines.
A lot of the knowledge tricks that modern engines do require depth or other things that didn't work on older hardware, deep blue was engineered to brute force a lot of things because brute force in the 90s worked better. Historically all sorts of things were tried for chess engines abandoned and tried again. Chess engine dev (and AI in general) is very cyclical; old ideas get returned to and retried as the hardware changes and evolves. Devs from past eras were smarter and more knowledgeable than we give them credit for. Heck, some of the very first engines for checkers and chess were neural nets (of a sort).
It also is not clear to me they didn’t just stop playing once they had +5, letting the clock expire, seeing as the opponent has no feelings or expectation of fair play. The game is detectably over at that point.
BTW, I also played a few games, 2400+ player on Lichess, I had no chance. My impression is that the claim by this author is correct. Or I am overrated :-)
The author caveats things near the end by giving the disclaimer about computer ratings but still goes too far in downplaying the difference IMO.
This is not at all to take away from his incredible work ethic, and his position as one of the top players of all time.
In a normal world this is hardware you should still be able to go play a game against at either at some IBM building, the Smithsonian, or whatever.
There's a point where you stop playing the engine and are just playing the humans behind it through a thinly disguised proxy.
I don't think that line was reached here, but to avoid confusion, it's not unreasonable to expect that the engine remain frozen for the duration of the competition.
That happened in game 6, when the computer sacrificed a knight for a pawn to wreck Black's defense, which Kasparov thought the computer wouldn't do because it wouldn't look deep enough past the material loss, but the computer knew to do it because IBM had added it to the opening book. This controversy was separate from another in game 2 where Kasparov also accused IBM of cheating, where Kasparov expected the computer to grab some material gain but it played more positionally instead and Kasparov thought the computer wouldn't find that line without human intervention.
https://en.wikipedia.org/wiki/Deep_Blue_versus_Garry_Kasparo... https://en.wikipedia.org/wiki/Deep_Blue_versus_Kasparov,_199...
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.
The machine was disassembled shortly after the tournament and Kasparov never accepted the offer to play it again. As a result the true moment where a computer first bested the world champion is not recorded and is likely to have occurred in someone's living room.
What happens in training doesn't count.
I'd have liked to see a backport of something more like Leela, i.e. more human-like evaluation with less search. Leela's neural net is bigger than Stockfish's NNUE but it's slower and static. I heard years ago that Leela searching 35 nodes per move was around equal to a human GM, and it should be much better now that they've redone Leela's NN architecture. My 4-core i5-3570S ran Leela at around 40 nodes/second but I unfortunately don't remember if that used all 4 cores or just one (Leela normally runs on a GPU at 1000s of nps). If the i5 is 100x faster than Carlini's Pentium Pro then that means around 0.4 nps, putting it above GM strength at classical time controls of around 2 minutes per move.
> ...because humans don't play against engines very frequently, there can be some small divergences between scores on the FIDE Elo ladder and the CCRL ladder…
This is precisely the problem. There are very few games between FIDE-rated players and CCRL-rated “players” under tournament conditions. The question of what FIDE rating a given CCRL rating would be equivalent to has been analysed extensively before and “small divergences” would be quite the understatement: https://talkchess.com/forum3/viewtopic.php?t=59332
In general ratings obtained purely by computer vs computer play are known to exaggerate the differences between computers compared to their performance against humans. This was known and discussed as far back as the 80s.
Ultimately the only way to discover the true strength of “Pentium Pro-fish” is for it to play a large number of games against FIDE-rated humans under strict tournament conditions.
> But if you happen to know a 2700+ Super GM who wants to try and defeat a 2026 chess engine playing on 1996 hardware, I'd be happy to accept the challenge!
Hikaru Nakamura? Has a history of playing chess computers in various odds matches and it could be interesting “content” for his entertainment brand. But really any of them might be interested if the financial terms were satisfactory.