Author: Christophe Theron
Date: 17:39:37 07/01/02
Go up one level in this thread
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
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.