Обсуждаем языки программирования

Windows

 

Думаю, что нынешнюю версию Греки я в турнир выставлять не буду.
Вот если к осени напишу новую версию, там посмотрим.
Кстати, по итогам наших тут бесед решил попробовать написать её на чистом C; если что случится с моим рассудком - прошу во всём винить atoku

 

Windows 3.1: mostly assembly language, some supplied applications coded in C.

Windows 9x/ME: the 16 bit subsystem was salvaged from DOS and Win 3.1 and therefore was written in assembly language; the rest was a combination of assembler and C. Win 9x was designed to work well on suboptimal, older hardware (486s and such), therefore needed the speed advantage of assembly language. Remember that Win 95 was originally packaged as an upgrade from Windows 3.1.

Windows NT (which implies Windows 2000 and XP): mostly C, with some assembly language at the kernel and device driver level. The design goal of NT was said to be potential portability, and assembly language efficiency was a secondary concern. The portions in C were designed to be ported to other CPUs and platforms such as Alpha.

(http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=28914)

 

учитывая, что первая винда появилась раньше чем С++, то... это, может, на ядре NT пошел С++. и вообще, как можно на С++ написать API - в 95 году вроде MFC еще не было.

 

Ну, даже если Винда написана не целиком на C, есть ещё всякие коммерческие Юниксы.

 

а также есть всякие некомерческие линуксы. пусть все и по отдельности пишут, зато команда!

 

Правда, писать на ANSI C у меня духу, наверное, не хватит
Так что будет С99.

А чем хорош O'Caml?

 

Я имел в виду предыдущую версию стандарта, 89-го года.
Т.е. то, что gcc понимает как -ansi, в отличие от -std=c99.

 

Написал на Си генератор ходов, по тому же алгоритму, что и в Греке. Выигрыш по скорости на разных тестовых позициях составляет от 5 до 15% (это пока без тщательной оптимизации). Выигрыш по размеру исполняемого файла - от 5 до 10 раз

 

gcc / MinGW 3.4.4

 

Да, из плюсов там практически только std::string активно используется (эх, пришлось-таки вспомнить, с чем char* едят - сто лет такими строками не пользовался), да std::vector для хранения списков ходов и найденных вариантов - ну, тут замена на массив ещё более простая. А ходы я сейчас тоже в 16-битные short-переменные упаковал.
Заодно понял, что для игры помещать в ход какие-то дополнительные флаги, коды ходившей и взятой фигур и пр. - расточительство. ПОТОМУ ЧТО БОЛЬШАЯ ЧАСТЬ СГЕНЕРЁННЫХ ХОДОВ ПРОСТО НЕ БУДЕТ РАССМОТРЕНА ИЗ-ЗА ОТСЕЧЕНИЙ

 

Мой тебе совет - когда будешь писать генератор ходов, с первых же версий встрой команду perft для тестирования легальности генератора. См. http://mypage.bluewin.ch/romanhartmann/perft.html

Я писал генератор, наверное, в третий или четвёртый раз. И даже не столько писал, сколько адаптировал существующий код. И то, прежде чем значения perft стали совпадать с правильными, выловил штук пять багов...

 

Что-то мне припоминается, что современные компиляторы на 32-битных платформах 16-битные числа всё равно кодируют в 32 бита... Так что выигрыша/проигрыша может и не быть.

А скорость будет кушаться на операцию упаковки кода фигур (одно или два побитовых AND и ещё один сдвиг, например - ну, это в зависимости от реализации). Можно ещё, конечно, всякие битовые поля или объединения использовать - но тут надо уже на получающийся ассемблерный код смотреть, а это лениво

 

Кстати, из истории разработки движка автора странички видно, что он глубоко прочувствовал необходимость тестирования генератора:

# x-mas 2003, start to write a move generator
...
# august 2004, move generator works fine up to ply 5
# septembre 2004, fixed an ep-bug, move generator seems to work fine now
# july/august 2005, fixed several bugs (promotion bugs)
...
# February 2006, fixed some bugs in the movegenerator

 

А куда спешить-то?

 

После доработки кода напильником удалось достичь скорости в полтора раза большей, чем в текущей C++ версии Греки. Но это пока только генератор ходов и make/unmake. Надеюсь, в поиске тоже что-то удастся оптимизировать.