Author: Gerd Isenberg
Date: 11:47:09 02/16/04
Go up one level in this thread
On February 16, 2004 at 08:23:45, Vincent Diepeveen wrote: >On February 15, 2004 at 16:15:47, Gerd Isenberg wrote: > >>Congrats to the the Winner of the >> >> 13th international Paderborn Computer Chess Championships! >> >>Chrilly Donninger, Ulf Lorenz, Erdogan Günes - the multinational Hydra-team >>under the banner of the United Arab Emirates. Seems to be a perfect team ;-) > >Good job especially from Erdogan. Getting a book together in a few months time >is not so easy. Congratulations also to Chrilly, hopefully his future with the >Arab sponsor is secure now. > >>Thanks to Ulf Lorenz as organizer and all other participants for that great >>social event - like a family reunion and a great time. > >Organizing is a very hard task. Most do not even realize how difficult >organizing an event can be. > >>Hydra is/becomes probably the dominating chess-hard-/software combination for >>the next time. FPGAs may have more potential for further speedup than > >I'm missing the point here completely i guess. My idea is that that the cycle gap of factor 100 (3GHz versus 30MHz) may become smaller in the future, like 20 or so. And that in conjunction with much higher number of "instructions" per FPGA cycle, to implement an even more sophisticated eval and smarter move sorting. But it's all my wild guesses... >This is the first time its ultra >agressive play, which gives away pieces by the numbers, has been shown into a >tournament. Without exception any of its ponder moves would have lost the game >20-40 moves sooner. > >I remember 1998 very well when nimzo98 arrived. It was ultra agressive, far more >than any other engine and dominated very shortly a few tournaments. Yet in world >champs 1999 it was nowhere. Nimzo98 was commercial available. Hydra is not. And it will become x-times faster in a relative short time. > >There is just a few months to go to the world champs. Let's see how it will be >doing there. Yes. > >>GP-processors (still 30MHz), and the PCI-bus becomes a bottleneck doing three >>plies plus quiescence. They "easily" may use more like 8/16/32... instead of > >It is impressive that with a hardware cpu they nearly search as deep as >Shredder. > >>four dual xeons or whatever with two FPGA-cards each. Not to mention Chrilly's >>further improvements combined with Ulf's well-founded parallel know-how and >>Erdogan's unorthodox and vicious opening lines... > >First of all, Chrilly has written all the code, not Ulf. Ulf is hosting the >machine there and making coffee. And what about the parallel stuff? >Within the Hydra team itself there is >disagreement about what will happen when a card gets more nodes a second. They will try. PCI-bus will become 10-times faster. > >My opinion is similar to that of Chrilly. That is that if you get more nodes a >second, that it will be harder to get a similar speedup, because accessing the >hashtables gets harder. > That's true, a kind of dimishing returns. But may be Chrilly will find a way to do four plies with some more sophisticated move sorting without hash, eg. some hints from eval.... >Ulf never has had a program above 1000 nodes a second, unlike Chrilly and i do, >which means that he still is in the phase to get all the cpu's to work. But 1000 nodes of that quality is not that bad. > >Now with 500 cpu's he sure has a point there, but at the current amount of cpu's >(8 going to 16 in the world ict4 leiden tournament) that should not be a problem >as it gets 16-18 ply anyway in any given position. > >I didn't see it have any big differences in search depth middlegame versus >endgame, and was pretty amazed by that. But that's probably a result from not >using hashtables the last 6 ply of the search. > >So i assume that the big advantage of Brutus will be in the world champs 2004 >when it gets 1-1 in a knockout game. In the 25 10 that follows then to decide >who goes on to the next round, getting 16 ply is a huge advantage of course. > >Especially against the 9 ply that i might get in such a case. Note that it is >not sure whether i will show up there. I will decide that after ict4. > >Yet the search problem from Hydra in the future has already been shown clearly. >It won't search any deeper in the future either. > >Way bigger branching factor than software has. > >This is very trivial shown by the experiment that i did at the 512 processor >machine where i showed that not using a shared hashtable last 10 ply will lose 5 >ply of search depth when compared to using it. > >This loss was already clearly visible in Hydra. It forward prunes everywhere in >the tree and very primitive in the last 3 ply hardware, just like shredder. > Primitive like Shredder ;-) Seems to work. >Also the algorithm they use does not scale. they ship around the entire >hashtable from node to node. > >I do not think that going from 8 to 16 cards will therefore be a big >improvement. Hydra needs 4 times more bandwidth a node than it is using now to >be able to do that. > >It's now having 4 nodes. To share hashtables it is doing a broadcast. > >So that's 4 broadcasts and the bandwidth load is therefore 4 * 3 = 12. > >Or N * N-1. > >With 512 fpga cards and 256 nodes that would be 256 * 255 = 65280 > >I hope you realize i didn't take into account PCI bus here yet. > >Hydra doesn't scale at all, so i do not see any problem. It gets effectively >around 4 million nodes a second now or so and is not even timing how much of the >total time it is searching is dedicated to jobs to the cpu's. What i mean is. >They should time how efficient they use the fpga cards. For example if you give >a single fpga cpu from the 10 seconds that a search takes, you give it 3 jobs >which takes in total 4 seconds from the fpga, then you use it 40% effectively. >When i guessed that they effectively use the fpga cards to get 500k nps from >each card then the team was quick to take that over, so i guess the efficiency >at which the fpga cards get used is very low. > >If it would get faster FPGA cards, then trivially that causes a major problem >because doing more than 3 ply in hardware is very difficult. You have hardly >move ordering in hardware. It's very close to minimax search. Chrilly has >managed as the first hardware programmer to use killermoves (deep blue didn't >even use them). that's very good from Chrilly. Even losing a clock to >killermoves means that you still face major problems. > >Chrilly doesn't have an easy job there. > >Effectively i am very sure that a 8 processor opteron for a software program is >faster than 8 fpga cards 30Mhz are. Yet the huge advantage is of course that a 8 >processor opteron is hard to order now, they are only in beta. > >When ordered they cost perhaps $100k and fpga cards cost only $3000 a card and a >4 node cluster dual Xeon 2.8Ghz costs less than $20k. > >Not sure whether university paderborn has bought it in at a commercial price. >Usually universities order hardware factor 2-3 more expensive than i would've >bought something. > >>But that will encourage others profis as well as amateurs to make further >>progress too - a new challange! > >Progress is there every year. > >>The Hydra-Fritz score-graph from both sides was really amazing. >>Fritz had a kind of sinus-chart with a growing, rather huge amplitude and a >>period time of circa 12 moves iirc, Hydra showed an ascending straight line ;-) > >Nothing new here, Ed Schroeder had this already with Rebel in 1990 and in >1998-1999 Bruce Moreland was known for having the lemma that there was a bug in >Ferret when score would deviate a lot from move to move in its disadvantage. > >>Congrats to the second, Fritz by Frans Morsch, Mathias Feist and the third, >>Stefan Meyer-Kahlen's Shredder, a bit unlucky this time with the book-line >>against Fritz. Not to forget Muntsin and Munjong Kolss and their Ikarus. >>Fourth place - best Amateur! >> >>IsiChess got very lucky 3.5/7. >>I consider Yace and SOS stronger than my program, and they had deserved a better >>score. But of course (bad) luck has huge influence in a seven round >>Swiss-tournament. > >A 7 rounds swiss tournament gives a winner. Nothing else. > >Hydra won clearly so congratulations to the hydra team! > >>About the games of IsiChess i'm a bit unsettled. >>Very weak games against Sos, Ikarus and Shredder and three "fitting heuristic" >>wins with thanks to the opponents. Matador's handling of the Mashall gambit was >>quite a bit "suicide". Comet overestimated his piece play and bishop pair >>against connected passers and Anaconda had to solve some fail lows, while >>IsiChess was convenient with ponder hits and "self"-play. > >Yes the programs with small work on the knowledge and major work on search and >in your case bitboards, they are going down slowly. > Bitboards are simply setwise presentations of chess related properties. Of course there is no contradiction between bitboards and knowledge ;-) >Let's see how you do in ict4. Faster level should favour you a bit more than >here. > Diep is still strongest in infinite thinking mode? >>Cheers, >>Gerd
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.