Author: Robert Henry Durrett
Date: 18:42:42 07/01/02
Go up one level in this thread
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.]
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.