As described here, gke is the GoKnot engine interface. Gke allows
programs (not only GoKnot) to use different Go engines. These pages and the first version of the programmer's toolkit
are an open proposal to anybody who develops or plans to develop Go software (engines or programs). This page
describes the design guidelines which lead to gke and what GoKnot users should understand about engines.
If you plan to write gke, continue to this page.
| | |
| | |
|
|
|
|
|
- Gke is CPU-level industry standard compatible. In other words: gke engines are binaries aimed to for Intel/AMD
class machines. That probably covers over 99% of the desktop computers in the world. (CPU-level incompatible
machines range from Sinclair Spectrums to Apples and are just living anecdotes.)
Ignoring the fact that there exists a standard, and pretending to write code for abstract platforms such as Java
or .NET which need translation at runtime, would penalize performance in about a decade compared to highly optimized
Intel/AMD class code.
- Following the same idea, the winning (for may be 95% to 5%) file format used to store the binary is: The Windows dll.
That is not a limitation for running gke in Linux. All you need is wine, the Linux compatibility package. As
mentioned here GnuGo via gke in Linux outperforms the same GnuGo compiled
as a native Linux binary with gcc.
This is because of the superior optimization quality of Windows development tools, not to gke.
A normal engine does no graphic or windowing output (the part in which Wine is still pretty green). It seldom calls the operating
system: just to allocate RAM or use a mutex. Except for that, and such basic functions are extremely efficient in both
systems, there is no difference between running an engine in Windows or in Linux. Wine is not an
emulator.
- Gke is a naturally multi-CPU/multithreading interface. Is not complicated to link non reentrant code, such as GnuGo, via
gke (the full source code is in the toolkit, as an example). The interface clearly separates functions that should return
immediately from functions that control supplying (one or many) CPUs to the engine. If the engine can divide its job between,
e.g., 64 CPUs, it tells GoKnot and GoKnot provide 64 threads each one running on a different CPU. (If the hardware can do it.)
- Gke is a naturally scalable interface. Engines implement whatever their author decides. GoKnot has a standard way to
enquire what is supported. The interface is open to the needs of the developer community. The same applies to gke options.
Simply: Any version of the engine links with any version of GoKnot. What is not supported or did not exist when the program
was released, won't be available, and the rest will be.
| |
If you want to run GoKnot under Linux, you need this:
|
| | |
|
|
 | |  |
|
What a user needs to understand about engines.
| |
 | |  |
|
|
Only two fundamental ideas are required:
 |
GoKnot is stupid (in terms of Go). Only the engine understands Go. GoKnot just knows the basic rules to
decide if a move is legal and draws territory according to the following predictable and unambiguous rules:
1. A connected area of void board cells is indivisible
2. It is either Black, White or Nothing.
3. Black, if and only if, surrounded by black or dead white stones.
4. White, iff, surrounded by white or dead black stones.
5. It is nothing in any other case.
GoKnot does not decide which stones are dead, it asks the engine. The resulting territory
will only be ok, if the game was played to the end. (It is not necessary to fill dame points.) When you ask for position
evaluation, GoKnot asks the engine. This is why both results of "Brief game state" and "Verbose game state" only match when the
game is played to the end.
Also, GoKnot considers that a game is finished, if the evaluation range returned by the engine has identical minimum and
maximum values and the engine's best moves list is empty. (This applies to "Verbose game state", not to the timer, the
timer stops after two pass moves.)
|
 |
Different engines, not only evaluate or play different, but they also support different features. In
the future, you will see engines explain the reasons of their moves in humanlike form: Setting labels on the board and
referring to those labels in plain text descriptions of a position saved as SGF remarks. The current gnu_link.dll
engine keeps everything interesting about the analysis of old GoKnot versions and makes its useful. In addition, some
information returned by the old analysis has been dropped because it was too GnuGo specific and the way it was displayed
changed from version to version.
|
| | |
| | |
|