Author: Vincent Diepeveen
Date: 19:40:53 07/01/02
Go up one level in this thread
On July 01, 2002 at 21:42:42, Robert Henry Durrett wrote: >On July 01, 2002 at 20:39:37, Christophe Theron wrote: > >>On July 01, 2002 at 11:42:59, Robert Henry Durrett wrote: >> >>>On July 01, 2002 at 08:32:15, Vincent Diepeveen wrote: >>> >>>>On July 01, 2002 at 02:32:48, Gian-Carlo Pascutto wrote: >>>> >>>>>On June 30, 2002 at 23:09:32, Robert Hyatt wrote: >>>>> >>>>> >>>>>>>For a tournament, a text GUI would be doable. >>>>>> >>>>>>Looks _very_ hard. All the book access code is in the GUI. The learning >>>>>>is in the GUI. All the option setting is in the GUI. >>>>> >>>>>Come on, he's a professional. This would be trivial to deal >>>>>with. >>>> >>>>No it's not trivial. Let's take chessbase >>>>as example. First of all the GUI belongs to chessbase, not to >>>>Frans. So that would mean we already have 2 persons involved. Frans to >>>>make a C version of his engine, Mathias to make a textmode editor. >>>> >>>>Loads of things to modify. I would reckon on a few months fulltime work >>>>here. What we must not underestimate is the communication to the engine. >>>> >>>>If that doesn't get changed, you have a *major* problem then. >>>> >>>>Frans can't adress the openingsbook himself simply, unless he gets the >>>>100% same hashing like the interface does, or he must be able to >>>>parse some special textformat which the interface outputs and convert it >>>>to his own. >>>> >>>>DIEP's windowsGUI protocol allows bookmoves to be shipped from GUI to >>>>engine. I bet most are not capable of doing that. It was *not* trivial. >>>> >>>>So basically we talk about a textmode interface around the engine quest >>>>then, just like we have one around our engine. >>>> >>>>In short making a new protocol, knowing that all kind of great windows >>>>things do not work under most unix flavours (including linux). >>>> >>>>Frans had one in the past of course, so we basically talk about book >>>>code he has to take over. Though it's not trivial, he would manage of >>>>course to do so. >>>> >>>>Then he has another year of work to make an engine in assembly for the >>>>processor he can run at. >>>> >>>>We all know he's not going to invest the time to do so, i would not >>>>advice him to do that. >>>> >>>>I'm in C. Easy talking for me. Very portable. It was a design choice >>>>from me to keep an engine which has its own book and own interface. >>>> >>>>So a simple other flag and a windows engine gets a complete stand alone >>>>engine. >>>> >>>>One thing we tend to forget, is that if you are completely optimized >>>>for x86 in assembly, which took years of time, >>>>that the it is *very* hard to get the same performance out of for >>>>example a R14000 processor. That also requires quite some time! >>>> >>>>Then there is the problem of testing. I can test everything at any >>>>machine, except for the scaling and bandwidth. Whatever the major >>>>differences in architecture, the program code *itself* can get tested >>>>to be working bugfree. >>>> >>>>In assembly you are 99.99% of your time busy debugging (if not more >>>>of the time). >>>> >>>>Writing it to C is simply no option, because you need years of work >>>>to get assembly code optimized to the same level. >>>> >>>>>>I was thinking only about a conversion to X86 unix, as in linux. The >>>>>>"syntax" is reversed between microsoft and GAS, which means _every_ line >>>>>>of assembly gets modified. >>>>>> >>>>>>A _big_ undertaking. Even without the problem of different architectures. >>>> >>>>Crafty has some inline assembly for example for >>>>locking both visual c++ compiler and for the linux thing. If i compare the >>>>2, an easy 'rewrite' is already not an option. >>>> >>>>Compilers are not the same, so you must take that difference into >>>>account too when using inline assembly. >>>> >>>>>intel2gas, gas2intel >>>> >>>>All with all a rewrite from a great graphical interface for windows >>>>to a poor stripped text interface for unix i wouldn't advice to chessbase :) >>>> >>>>They would earn for a year no money :) >>>> >>>>Doesn't take away that Frans might be forced anyway to make a C version from >>>>Quest. We get so many new processors, McKinley, Hammer, and they all have >>>>extensions. So to program in assembly for those, i am not jealous if someone >>>>is doing that :) >>>> >>>>If he does, obviously i love to hear the assembly versus C difference he >>>>gets, as that would be the first good measurement of a well tuned assembly >>>>program that gets rewritten into C. >>>> >>>>Fact that there nearly doesn't exist a program that has 2 versions: >>>>a well optimized C version AND a well optimized assembly version, >>>>already gives insight how hard it is to keep doing the double work. >>>> >>>>>-- >>>>>GCP >>>> >>>>Vincent >>> >>>My impression from the above is that "optimization for a specific >>>microprocessor, computer, or architecture" is very common and is THE way to >>>produce the highest-ranked chess engine. >> >> >> >>It's completely wrong. Chess Tiger for example is written 100% in C. >> >>IIRC Shredder is as well. And Junior and Gandalf too. >> >>I'm not even sure Fritz is 100% assembly. Maybe it's written in C now. >> >>The way to produce a high level chess engine is to have ideas and to be able to >>test many of them inside a decent framework (performance-wise). C is excellent >>for this. ASM used to be but is not anymore. >> >> >> >> >>>As these things change, the optimization processes must be repeated. >>> >>>Is this an accurate representation of the true state of affairs in "the world of >>>computer chess?" >> >> >>No. >> >> >> >> Christophe > >I guess that leaves me wondering why others here have said it would be too >dificult to put Fritz [Deep Fritz] on larger computers "because it is written in >assembly language." There is an obvious disconnect here. Which is correct? > >Signed, > > >Confused. [Bob D.] Fritz = assembly, that's what it is. 2 million nodes a second at a dual k7 with a non preprocessor and WITH pruning, if i may ask you :)
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.