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