Обсуждение интерфейса для доступа к ЭБ

[Kallisto]

В этой ветке предлагаю программистам обсуждать интерфейс для доступа к ЭБ. Так чтобы после согласования любой движок мог без всяких проблем использовать общую ЭБ, предоставляемую оболочкой.

Вот первый вариант интерфейса.

#define DB_DRAW      10000

#define DB_WIN       10001

#define DB_LOSE      10002

#define DB_UNKNOWN   10003

#define DB_NOT_FOUND 555555





// флаги для доступа к базе



#define DB_IN_MEMORY 1





// коды для обозначений шашек



#define EMPTY	1

#define WHITE	2

#define BLACK	4

#define KING	8



// т.е. код белой дамки - 10



struct EdBoard1

{

// все поля идут по порядку a8, c8, и т.д. до g1

unsigned char board[32];

};



struct EdBoard2

{

unsigned char *wman;

unsigned wman_cnt;



unsigned char *wkings;

unsigned wkings_cnt;



unsigned char *bman;

unsigned bman_cnt;



unsigned char *bkings;

unsigned bkings_cnt;

};



// интерфейсный класс для доступа к базам

struct EdAccess

{

// загрузить базы

unsigned Load() = 0;



// получить тип базы

char *GetBaseType() = 0;



// оценка позиции (всегда ход белых)

int GetResult(EdBoard1 *board, unsigned flags) = 0;

int GetResult(EdBoard2 *board, unsigned flags) = 0;



// получить указатель на таблицу по материалу

unsigned GetTable(unsigned wm, unsigned wk, unsigned bm, unsigned bk) = 0;



// получить указатель на таблицу по материалу и по наиболее продвинутой шашке

unsigned GetTable(unsigned wm, unsigned wk, unsigned bm, unsigned bk, unsigned rank) = 0;



// проверка загруженности таблицы целиком в память

unsigned IsTableInMemory(unsigned table);



// получить индекс в таблице

unsigned __int32 GetIndex(EdBoard1 *board) = 0;

unsigned __int32 GetIndex(EdBoard2 *board) = 0;



// получить оценку по указателю на таблицу и индексу

int GetResult(unsigned table, unsigned __int32 index, unsigned flags) = 0;

};





// функция интерфейса экспортируемая из dll

__declspec(dllexport) void __stdcall EI_EGDB(EdAccess *eda)

{

// здесь должен быть код

// сохраняющий указатель на интерфейс во внутренние переменные движка

// вызывающий загрузку базу?

}

Здесь я сомневаюсь по одному моменту. Хватит ли 32-х бит для индексирования больших таблиц?
Если нет, то стоит ли все базы индексировать 64-мя битами или для младших баз все-таки оставить 32 бита?

[NS]

А зачем такие сложности?
Не проще ли дать просто ссылку на Таблицу «board»?
У меня, на делфях миллион копирований в другой формат представления доски занимает 50 мс.
20 миллионов копирований в секунду.

А авторам движков намного проще — просто скопировал доску в нужный формат, вызвал функцию с сылкой на таблицу в этом формате, и получил значение.

И дополнительно нужна вторая функция возвращающая размерность ЭБ.

То есть прямого доступа к ЭБ нет, есть только две функция — первая возвращает оценку, вторая размерность ЭБ.

[Kallisto]

Ничего не понял. Позицию нужно просто скопировать в нужный формат. Причем предоставляются два формата на выбор.

Размерность базы возвращает Load(). Или ты о чем-то другом?

[NS]

Я о том, что зачем преобразовывать позицию в 32-битное либо 64-битное число. Её можно просто скопировать в 32-байтный массив, а преобразование в индекс уже делать в оболочке.

[Kallisto]

То есть прямого доступа к ЭБ нет, есть только две функция — первая возвращает оценку, вторая размерность ЭБ.

Еще есть функция получить результат не по позиции, а по индексу, если вдруг движок считает, что он сумеет более эффективно вычислить индекс.

Функция вычисления индекса просто для полноты картины. Возможно есть еще какие-то микрооптимизации.

[Kallisto]

Я о том, что зачем преобразовывать позицию в 32-битное либо 64-битное число. Её можно просто скопировать в 32-байтный массив, а преобразование в индекс уже делать в оболочке.

Так и есть. Вызывай вот эти функции:
int GetResult(EdBoard1 *board, unsigned flags) = 0;
int GetResult(EdBoard2 *board, unsigned flags) = 0;

[NS]

Функция вычисления индекса просто для полноты картины. Возможно есть еще какие-то микрооптимизации.

Эта функция будет меняться от изменения формата ЭБ, поэтому проще её делать под текущий формат (всё-равно потом придется менять)
И если сейчас на индекс достаточно 32 бит, то зачем использовать 64?

[Kallisto]

Перед использованием движок спрашивает формат базы. И если вдруг он знает, то может взять вычисление индекса на себя, а может передоверить оболочке. Зачем его лишать такой возможности?

Нужно сейчас придумать такой интерфейс, чтобы потом его уже менять не нужно было. Просто потом будут другие реализации ЭБ. И чтобы старые движки смогли легко их использовать без каких-либо модификаций кода.

[NS]

Ну, я уже высказался. Раз для текущего формата и текущей размерности хватает 32 бит, то наверно нужно столько и сделать.

[Kallisto]

А что делать когда их станет не хватать?

[NS]

А что делать когда их станет не хватать?

Поменять формат базы (который движок может получить), и в этом случае движок должен использовать более медленный, но абсолютно универсальный формат 32-байтного массива.

[Kallisto]

Мне больше нравится сразу перейти на 64 бита.

[NS]

Да, только если потом будут использоваться сжатые (неполные) ЭБ, то скорей всего расчет индекса будет иной.

[Kallisto]

Нет, индекс не имеет никакого отношения к сжатию.

[NS]

Почему это не имеет? Для лучшего сжатия близкие (похожие) позиции размещаются рядом, и должны иметь близкий индекс. Плюс, при неполных базах, например в базах с одинаковым числом шашек у обеих сторон, если храним позиции только с очередью хода стороны с наиболее продвинутой шашкой — вычисление индекса так-же меняется.

И вместо выигрыша в скорости от обращения по индексу получаем падение скорости на пересчет индекса в оболочке.

Или другой пример — в Чинуке таблицы разбивались по степени продвинутости наиболее продвинутой простой — так-же другой расчет индекса.

[Автор]

Сообщения