mhull wrote:Could a programmer from the future have dominated with micros in the 1980s? Is there a way to demonstrate this?
Yes, the search techniques get the branching factor down to 2 or better today. In the 80's it was around 6. A modern program transported to the motorola would blow the doors off of the software of the time.
Simple math.
Do you think the math shows that the software techniques required to achieve lower BF (and higher depth) would compensate for the potentially higher NPS of period software at both blitz and standard time controls?
I don't understand your question.
The NPS will be about the same on period hardware for the old software and the new using mailbox. It may be that the magics bitboards would work better on 32 bit than the old techniques. Not sure about that.
Modern programs compiled for the 68K CPUs would blow the doors off the older programs on the same hardware.
It sounds to me like you may be asking for something else, though.
I guess I'm asking if the new software techniques reduce "path-length-to-elo" on machines with "highly reduced MIPS".
For example, a 16-bit TI9900 machine a 3Mhz with 48K RAM. The strongest chess program on that architecture AFAIK was a David Levy program written for TI994A computer. A C player could handle its highest levels with relative ease.
Or consider the Novag Super-Constellation. Could that same hardware host a significantly stronger program?
mhull wrote:Could a programmer from the future have dominated with micros in the 1980s? Is there a way to demonstrate this?
Yes, the search techniques get the branching factor down to 2 or better today. In the 80's it was around 6. A modern program transported to the motorola would blow the doors off of the software of the time.
Simple math.
Do you think the math shows that the software techniques required to achieve lower BF (and higher depth) would compensate for the potentially higher NPS of period software at both blitz and standard time controls?
I don't understand your question.
The NPS will be about the same on period hardware for the old software and the new using mailbox. It may be that the magics bitboards would work better on 32 bit than the old techniques. Not sure about that.
Modern programs compiled for the 68K CPUs would blow the doors off the older programs on the same hardware.
It sounds to me like you may be asking for something else, though.
I guess I'm asking if the new software techniques reduce "path-length-to-elo" on machines with "highly reduced MIPS".
For example, a 16-bit TI9900 machine a 3Mhz with 48K RAM. The strongest chess program on that architecture AFAIK was a David Levy program written for TI994A computer. A C player could handle its highest levels with relative ease.
Or consider the Novag Super-Constellation. Could that same hardware host a significantly stronger program?
Yes.
For instance, I had a C compiler for the Commodore 64, which was an 8 bit machine. So C programs (e.g. CFish) could be made to run on it.
You might have to write an emulation layer for larger integer types, but the branching factor will dominate, even if the software runs much more slowly.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
mhull wrote:Could a programmer from the future have dominated with micros in the 1980s? Is there a way to demonstrate this?
Yes, the search techniques get the branching factor down to 2 or better today. In the 80's it was around 6. A modern program transported to the motorola would blow the doors off of the software of the time.
Simple math.
Do you think the math shows that the software techniques required to achieve lower BF (and higher depth) would compensate for the potentially higher NPS of period software at both blitz and standard time controls?
I don't understand your question.
The NPS will be about the same on period hardware for the old software and the new using mailbox. It may be that the magics bitboards would work better on 32 bit than the old techniques. Not sure about that.
Modern programs compiled for the 68K CPUs would blow the doors off the older programs on the same hardware.
It sounds to me like you may be asking for something else, though.
I guess I'm asking if the new software techniques reduce "path-length-to-elo" on machines with "highly reduced MIPS".
For example, a 16-bit TI9900 machine a 3Mhz with 48K RAM. The strongest chess program on that architecture AFAIK was a David Levy program written for TI994A computer. A C player could handle its highest levels with relative ease.
Or consider the Novag Super-Constellation. Could that same hardware host a significantly stronger program?
I remember someone 2-3 years ago ported Stockfish (5? 6?) to Commodore Amiga 1000 (1985, Motorola 68000 CPU), he was getting around 300 NPS per MHz. On 68020 14 MHz of Mephisto Roma, it would get NPS of about 4000. Tournament time control is about 150 seconds per move, or 600,000 nodes per move. For Stockfish 8, this is solidly in 2800+ FIDE ELO territory, while Mephisto Roma was 2070 FIDE ELO. From my data, the FIDE ELO of Stockfish 8 on 68020 can also be estimated: 1250 computer ELO software progress in 30 years, meaning taking care of FIDE ELO compression, 1250*0.66 = 825 FIDE ELO software progress, and 2070+825 = ~2900 FIDE ELO of Stockfish 8 on Motorola 68020. It is probably a bit inflated, because porting involves a factor of 2-3 NPS loss, but it is too solidly in 2800+ FIDE ELO territory.
So, a present day Stockfish on that Mephisto Roma 68020 board would probably be at least on a par with Kasparov and Deep Blue. Imagine what a stir it would have brought, had it appeared back then in 1987. Strong players played for fun blitz games with these machines, beating them quite easily, imagine Stockfish machine, which is even better at blitz (probably FIDE 3000 on 68020), killing them all.
Dann Corbit wrote: Yes.
For instance, I had a C compiler for the Commodore 64, which was an 8 bit machine. So C programs (e.g. CFish) could be made to run on it.
You might have to write an emulation layer for larger integer types, but the branching factor will dominate, even if the software runs much more slowly.
Main problem back then was not the CPU but memory.
You simply have no room to implement anything.
For that reason the programs of it's day on their hardware are still hard to beat.
Dann Corbit wrote: Yes.
For instance, I had a C compiler for the Commodore 64, which was an 8 bit machine. So C programs (e.g. CFish) could be made to run on it.
You might have to write an emulation layer for larger integer types, but the branching factor will dominate, even if the software runs much more slowly.
Main problem back then was not the CPU but memory.
You simply have no room to implement anything.
For that reason the programs of it's day on their hardware are still hard to beat.
How this is a problem for Commodore Amiga 1000 of 1985 (Motorola 68000 CPU), with its 512 kB DRAM? Porting of Stockfish on it is known, as I wrote in an earlier post. People could have had a 2800+ FIDE ELO engine (Stockfish 8) by 1985.
Laskos wrote:How this is a problem for Commodore Amiga 1000 of 1985 (Motorola 68000 CPU), with its 512 kB DRAM? Porting of Stockfish on it is known, as I wrote in an earlier post. People could have had a 2800+ FIDE ELO engine (Stockfish 8) by 1985.
It isn't. But specifically the C64 was mentioned and a lot of dedicated chess hardware was rather limited back then as well. Yes the Amiga's were amazing machines and hardware was going much faster than software at the time.
Laskos wrote:I took 5 top engines of their time separated by 4 fairly equal intervals of 7-8 years since 1987, thanks to Ed's porting to UCI of his beautiful old works.
Hardware gains are for one core.
Mephisto Roma (1987)
CPU: 68020 14 MHz
FIDE ELO: 2070
One can observe that software progression in 1987-2002 was fairly slow, slower than hardware progression. However, 2002-2017 saw extremely fast software progression and slow hardware progression. This is mostly due to such developments as Fruit/Rybka and Stockfish/Komodo.
In 30 years:
Total gain hardware: 150+300+100+70 = 620 ELO points
Total gain software: 100+250+420+480 = 1250 ELO points
Total gain hardware + software: 620+1250 = 1870 ELO points
FIDE ELO gain: 3300-2070 = 1230 ELO points
Compression of FIDE rating compared to computer rating: 1250/1870 = 0.67
There is a threshold when developers stopped to think about hardware and started to think about chess. With limited hardware there is no room to think about fancy algorithms. Formerly, OS and hardware knowledge was more important, while today is more important chess knowledge, statistic, etc.
Dann Corbit wrote: Yes.
For instance, I had a C compiler for the Commodore 64, which was an 8 bit machine. So C programs (e.g. CFish) could be made to run on it.
You might have to write an emulation layer for larger integer types, but the branching factor will dominate, even if the software runs much more slowly.
Main problem back then was not the CPU but memory.
You simply have no room to implement anything.
For that reason the programs of it's day on their hardware are still hard to beat.
How this is a problem for Commodore Amiga 1000 of 1985 (Motorola 68000 CPU), with its 512 kB DRAM? Porting of Stockfish on it is known, as I wrote in an earlier post. People could have had a 2800+ FIDE ELO engine (Stockfish 8) by 1985.
I think this begins to answer my question very well. For 8-bit architecture it could have been more challenging. But MC68000 was readily available in the early '80s.
Laskos wrote:
One can observe that software progression in 1987-2002 was fairly slow, slower than hardware progression. However, 2002-2017 saw extremely fast software progression and slow hardware progression. This is mostly due to such developments as Fruit/Rybka and Stockfish/Komodo.
how much of slowdown of 2002-2017 hardware progression was due to diminishing returns and how much was due to slowdown of moore's law?
fom 1987 to 2002 mhz increased over a hundred fold.
if mhz increase had kept up then we would dealing with over 150,000 ghz rather than 4000 mz
