Издательство Готовая книга




Программы играющие в Го, игра Го онлайн, электронные книги и лекции Го на видео  

Ассемблер x86 против C

kit144 на rugo.ru Любитель Го
17, May, 2004 14:56   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Автор

Весь текст ниже взят из переписки с Eugene D. Shelwien. Моего тут только несколько строчек, выделенных курсивом и резюме. Текст основан на трех письмах, поэтому, возможно, не совсем целостный, но все равно очень интересный. Пользуясь случаем, хочу еще раз поблагодарить Евгения за интересные письма.
Математика

В любом случае, я не думаю, что производительность ПО будет сильно выше, если его взять и переписать на ассемблере.

Во-первых, часто может быть выше в разы - хотя бы за счет деталей архитектуры, о которых компилятор "не знает". Скажем, FPU на x86 просто логарифм считать не умеет - только y*log2(x). Как ты думаешь, будет у меня разница если я попытаюсь вычислять такую функцию на сях и на асме?

Даже MSVC6 и то компилит из

void main(void)
{
int x = 66666*66666;
printf("%lf\n", 128*log(x) );
}

вот такое вот:

fldln2
subesp, 8
fldQWORD PTR __real@8@401a8e77be4000000000
fyl2x
fmulQWORD PTR __real@8@40068000000000000000
fstpQWORD PTR [esp]
pushOFFSET FLAT:
callDWORD PTR __imp__printf
addesp, 12

Intel - и то облажался

fld QWORD PTR 1_2il0floatpacket1 ;7.27
fldln2 ;7.27
fxch ;7.27
fyl2x ;7.27
fmul QWORD PTR 1_2il0floatpacket ;7.27
mov DWORD PTR [esp], OFFSET FLAT: ??_C@_04A@??6?@ ;7.27
fstp QWORD PTR [esp+4] ;7.27
call DWORD PTR __imp__printf ;7.27

Не говоря уж о том, что мне логарифм по основанию "e" вообще как-то нафиг не нужен :). Между тем log2 я в math.h отчего-то не вижу :(

Короче, уверяю тебя - математика даже минимальной сложности, написанная на асме, работает много быстрее :(.
Оптимизатор

Ну от ассемблера практическая польза у ЯВУ есть еще одна ;) Заключается она в том, что это не ассемблер ;) у меня такое ощущение, что руками делать то, что делает оптимизатор для кода (то есть, перестановку инструкций так, что бы они помещались в конвейер, оптимизацию использования кеша и т.д. и т.п.) руками не сделать. Точнее, не факт что будет лучше ;)

Гм. Это ты еще не знаешь, с кем связался :). Я вообще сишный компилятор (IntelC 4.5, в основном) использую чуть больше четырех месяцев - потому что завел сайт и оказалось, что некоторые мало того, что ничего не понимают в моих исходниках, так у них еще и на экзешники идиосинкразия :). В смысле, до того мне кроме асма как-то ничего не требовалось :) (ес-сно, для моих проектов; не для коммерческих) Так вот. Оптимизатора лучше, чем в IntelC, я не видел, но на то, что он компилит, все равно лучше не смотреть. Ни о какой автоматической оптимизации использования кэша просто речи быть не может (ты о выравнивании, что ли?). Просто потому, что развернутый код/выравненные данные очень легко могут в него не поместиться и я наблюдал подобное реально (душераздирающее зрелище - после установки inline на одну маленькую функцию, вызываемую два раза, программа вдруг начала работать раз в десять медленнее :).

В общем, единственное, от чего есть польза по скорости - это от разворачивания циклов с внутренними условиями - если это сделать вручную, то очень трудно будет потом что-то менять.

А вот по нескольким вещам, которые доступны мне при писании на асме, я очень скучаю. Во-первых, это макропроцессор - сишный несравнимо хуже и из-за этого в сложных проектах часто попадаются дополнительные препроцессоры etc. Во-вторых - глобальная оптимизация; например, я сделал макросов для определения/использования глобальных переменных и возможность доступа к ним относительно EBP (который должен при этом указывать в начало соответствующего буфера). Выглядит это так:

ifproc PrepareParamFiles
% define
local inpfile,outfile
NameBufLen = 256
dvd SourceLen
dvd SourceSeg
dvd TargetFil
buffer inpfile, NameBufLen
buffer outfile, NameBufLen
dvd SourceNam, offset inpfile
dvd TargetNam, offset outfile

PrepareParamFiles: pushad
mov esi,81h
mov edi,[d_SourceNam]
calls FetchFilename
edx,"Filename must be specified.",13,10
jc ItsError

; copy filename to output buffer and change its extension
push edi ; save inpfile
mov edi,[d_TargetNam]
calls FetchFilename
smov es,ds
jnc ReadOk
; generate output filename by self
mov esi,[s4s 0]
calls Truename
...
endm

а компилится в следующее:

60 pushad
BE81000000 mov esi,000000081
8B7D80 mov edi,[ebp][-0080]
E853000000 call 00000011E
BAD7050000 mov edx,0000005D7
7242 jb 000000114
57 push edi
8B7D84 mov edi,[ebp][-007C]
E843000000 call 00000011E
1E push ds
07 pop es
7313 jae 0000000F2
8B3424 mov esi,[esp]
E860000000 call 000000147
...

Как ты можешь заметить, однобайтовые относительные адреса несколько короче абсолютных ;). (Не говоря уж о том, что функции, определенные по ifproc/endm компилятся только в том случае, если в скомпилированном коде будет к ним обращение; по calls, например)

Но это все мелочи. А вот о том, что на любой из современных архитектур с поддержкой виртуальной памяти использование каких-то специальных средств для динамической аллокации памяти и т.п. - это полный бред, ты знаешь? Потому что для расширения (выравненного на страницу) блока памяти необходимо всего лишь отмапить дополнительную страничку по соответствующему адресу. В общем, все средства для эффективной работы с динамической памятью входят в состав любой современной ОС. (Любая RTL использует их + навернутый сверху собственный менеджер памяти).

Только вот использовать их при программировании на сях, например, я затрудняюсь. Фишка простая - при изменении размера ОСового блока памяти у него может поменяться адрес. А поскольку компиляторы ничего, кроме flat-модели не поддерживают, то автоматически использовать такой способ аллокации нельзя - каждый указатель в середину блока должен "знать" начальный адрес этого блока. А архитектура x86, между тем, поддерживает такое понятие, как "селектор".

Оказывается возможным, например, следующее:

...
mov edi,[d_BufferPtr]
cmp edi,[d_BufferSize]
jae ResizeOutBuffer0
ContinueWriting0: stos [e4y smp_Value]
mov [d_BufferPtr],edi
...

ResizeOutBuffer0: pushad
add [d_BufferSize],BufferSizeIncrement
mov eax,es
mov ecx,[d_BufferSize]
calls mResize
mov es,eax
popad
jmp ContinueWriting0

Причем все указатели на этот же блок, хранящиеся где-то в памяти в виде селектор:смещение будут _всегда_ ссылаться именно на этот блок, куда бы он ни уехал по памяти.

А компиляторы Си (из соображений портабельности? :) указателей с селекторами не поддерживает в принципе. остается либо при каждом обращении по указателю суммировать его с базой блока (подобное возможно за счет одного из "дополнений" в MSVC - тага __based - пример:

void *vpBuffer;
struct llist_t
{
void __based( vpBuffer ) *vpData;
llist_t __based( vpBuffer ) *llNext;
};

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

Может я и напишу когда-нибудь замену malloc etc на системных вызовах и __based'ных указателях... только в сложных случаях это может оказаться менее эффективно, чем стандартный способ - регистры закончатся в два раза быстрее. А вот селекторный вариант определенно быстрее - я проверял.

А уж как чудно malloc'омания отражается на функциональности программ... :). В частности, архиваторам нужна опция для указания размера словаря, в первую очередь, именно чтобы его не realloc'ить.
Ассемблер vs C

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

Вот-вот. Как ты думаешь, навязывание мне авторами компилятора flat-модели может влиять на выбор алгоритмов? Или... вспоминается мне, например, прикол, когда я написал макрос для выравнивания функций по parity младшего байта адреса :).

mov bp,offset OpTable
GetNextChar: lodsb
mov ah,0
shl ax,1
add bp,ax
mov bp,[word ss:bp]
inc bp
jp ExecuteOperator
loop GetNextChar
...
ExecuteOperator:jmpbp

Это я интерпретатор писал, еще в XT'шные времена :). Там было некоторое множество операторов, и для их разбора я изобразил trie в виде наборов табличек, индексируемых очередным символом и содержащих либо адрес очередной таблички, либо адрес функции-обработчика. Которые отличались, как видно, по parity младшего байта адреса минус один - это оказалось несколько быстрее всех прочих приходивших мне в голову решений :). Дык вот. Слабо заставить компилятор сей скомпилить функцию по адресу с такими ограничениями? :)

Или более серьезный пример - понадобился мне как-то словарь в виде тернарного дерева. Так вот когда я сделал ветвление после сравнения символов не по больше/меньше, а по parity... можешь себе представить, насколько улучшились характеристики.

Или битовые операции те же. Ты знаешь, что на x86 есть возможность работать с битовыми массивами длины до 2^31, причем в обе "стороны" от указанного адреса? Т.е. команды для этого есть. Типа

mov eax,-10000
m0:
btr [ArrayEnd],eax
inc eax
jnz m0

(это к вопросу о соотношении строк в сишном/асмовском исходниках)
1. Умножение

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

Причина: компилятор Си поймет запись

low += cumFreq * (range/= totFreq);

правильно, а вот

low += (cumFreq*range)/totFreq

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

mov eax,cumFreq
mul range
div totFreq

и получу _точный_ результат :).
2. Самомодификация

Были времена, когда это была чуть ли не панацея. После появления кэша кода, увы, с этим стало хуже :). Только вот в случаях, когда тебе нужно вызывать некую функцию на каждой итерации цикла, пока не случится нечто, а потом уже не нужно... Нет, можно, конечно, сделать две копии цикла :) Правда, никакой оптимизатор в этом тебе помогать не захочет. А вручную - задолбаешься синхронно вносить изменения во все копии.

В общем, вот есть у процессора (все еще :) возможность модифицировать код. А из ЯВУ это доступно с трудом, непортабельно etc. Ну и кто в этом виноват? :)
2a. Генерация кода

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

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

Аналогично, изредка требуется возможность вернуться из функции несколько не туда, откуда вызывали. longjmp и setjmp, вон, даже сочинили. Вот только это решение за счет потери производительности :(.

Ну и есть еще один трюк, который я очень люблю... но уж он-то к ЯВУ отношения не имеет точно :)

00000057:
BEDF01 mov si,001DF ; загружаем смещение
84BE2202 test [bp][00222],bh ; никуда ничего не пишем
^^^^^^
58 pop ax
9C pushf
0E push cs
E8C9FF call 00000002D ---------- (2)
E80200 call 000000069 ---------- (3)
5E pop si
CF iret

0000005B:
BE2202 mov si,00222
^^^^^^
58 pop ax
9C pushf
0E push cs
E8C9FF call 00000002D ---------- (1)
E80200 call 000000069 ---------- (2)
5E pop si
CF iret

Это, конечно, оптимизация по размеру кода в чистом виде, но нередко может помочь и по скорости - все-таки избавляемся от лишнего перехода.
4. Флаги

На большинстве процессоров кроме обычных регистров есть еще и флаги результата и переходы по ним. Никакой их поддержки в ЯВУ не присутствует, а понимать, что

uint tmp=low;
low += cumFreq * (range/= totFreq);
if (low<tmp) Carry++;

нужно компилить как

[...]
add low,eax
adc Carry,0

, не громоздя лишних проверок... Это выше способностей IntelC, по крайней мере :)
5. Стек

Опять же, обычно он есть. Только вот кое-кто его узурпировал для хранения параметров функции. А что можно что-нибудь туда пихать, чтобы выбрать потом в обратном порядке (и дофига других применений можно придумать) - посчитано лишним :).

Не говоря уж о том, что в современных ОС при возникновении прерывания в стек программы ну никак не может ничего записаться. Так что ESP, как бы, можно пользоваться вполне свободно - что очень важно, когда это один из всего восьми доступных регистров. Но увы.

А уж о том, что стековыми операциями можно очень быстро (и удобно) читать что-то из памяти, ходить по связанным структурам по POP ESP etc... лучше и вовсе не вспоминать, чтоб ностальгия не замучала :)
Резюме

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

Но даже если все написанное выше не особенно понятно (после публикации этого текста мне стали приходить письма с общим содержанием вида "какие люди!"), то осознание того, что языки программирования C или C++ не всегда подходят для решения любых задач, очень полезно. Мало того, как можно видеть, эти языки программирования не являются близкими к ассемблеру, хотя это заблуждение является общепринятым.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Re: Ассемблер x86 против C
Олег Попов на rugo.ru Любитель Го
17, May, 2004 15:31   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

"шутка, повторенная дважды, становится в два раза смешнее"


Re: Ассемблер x86 против C
Илья Ветров на rugo.ru Ценитель Го
17, May, 2004 15:41   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Кит , это конечно интересно и местами даже понятно . Но вопрос все тот же - НУ И ЧТО ?

Да , для некоторых алгоритмов ручная оптимизация на асме повышает скорость выполнения программы , с этим никто никогда не спорил . На сколько повысит в твоем конкретном случае ? Как часто вейчный искусственный интеллект будет вычислять логарифмы ?

Да , для некоторых алгоритмов существенна свобода в обращении к памяти . Бывает нужно быстрое и частое перераспределение динамической памяти и даже самомодификация машинного кода . Но нафига это надо в обсуждаемой общеалгоритмической задаче ?

И почему надо начинать проектирование алгоритма с выбора системы программирования ? Ты уже все алгоритмы продумал и отладил , осталось оптимизировать ?

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



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

Re: Ассемблер x86 против C
kit144 на rugo.ru Любитель Го
17, May, 2004 16:53   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Пока ещё не видел обсуждение алгоритмов.

А по поводу асма так вы сами меня постоянно цепляете.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Re: Ассемблер x86 против C
IlyaM на rugo.ru Гость
17, May, 2004 17:04   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

kit144 писал:

> Пока ещё не видел обсуждение алгоритмов.
>
> А по поводу асма так вы сами меня постоянно цепляете.

И будут цеплять пока ты не перестанешь утвержать, что нынешние программы играют плохо потому что они написаны не на асме. Цитата: "осознание того, что языки программирования C или C++ не всегда подходят для решения любых задач, очень полезно". Почему то ты упорно не хочешь принять тот факт, что аналогичное утверждение про ассемблер тоже верно. Рискну утвержать, что очень узок круг задач, для который написание кода на 100% на асме будет правильным решением.


Re: Ассемблер x86 против C
Ушастый Заяц на rugo.ru Гость
17, May, 2004 18:53   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Не понимаю, почему современные музыканты пишут музыку какими-то дурацкими нотами и аккордами. К чему всё это? Это же крайне неоптимально! Тогда как любому ёжику ясно, что редакторы wave-форм типа CoolEdit или AudioLab позволяют работать непосредственно с формой сигнала, контролировать с точностью до единичного отсчёта напряжение, подаваемое на звуковую карту. А если вам нужно многоголосие или там эффекты всякие, типа реверберации, никто не мешает воспользоваться суперпозицией нескольких синусоид, которую легко вычислить хотя бы на встроенном калькуляторе Windows. Настоящую музыку, полностью использующую мощь звуковой карты, можно создавать только так - прямым доступом к каждому из 44100 отсчётов в секунду.

Да, и почему ещё эти чудики-поэты и писатели пишут свои нетленки во всяких Вордах и Нотепадах, крайне неоптимально используя пространство свободного места на странице? Все в графический редактор
Paint, и - по пикселу, по пикселу... Отговорка, что так буквы рисовать неудобно - для лентяев.

Re: Ассемблер x86 против C
Damir на rugo.ru Гость
17, May, 2004 22:11   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

>> навязывание мне авторами компилятора flat-модели
AFAIK - это родная модель для всех win32 и win nt систем.


>> Может я и напишу когда-нибудь замену malloc etc на системных вызовах и __based'ных указателях... только в сложных случаях это может оказаться менее эффективно

Насколько я знаю такие версии CRT существуют. Здесь мы видим типичный кул-хацкерский подход: "Чужим кодом не пользуюсь, потому что там будут баги, а я пишу код без багов" И пальцы веером (шутка). На самом деле я бы обратил внимание на одно предложение:

>>мне кроме асма как-то ничего не требовалось :) (ес-сно, для моих проектов; не для коммерческих)

То бишь человеку просто нравится писать на асме - вот он и пишет - но только для себя. Для заказчиков он пишет все-таки на С.

Главный минус ассемблерной заточки программы под конкректный процессор - потеря портабельности. Даже не портабельности, а вообще - привязка под конкретный процессор конкретного производителя. Именно поэтому в компиляторах оптимизация под конкретные наборы инструкций реализуется только как опция, а не как фича. Лет этак 6-ть назад помню был очень зол когда какая-то игрушка мне выкинула "This program require processor with MMX support" (может чуток ошибся в формулировке, но идею думаю поняли), а запускал я ее - игрушку - на тогда еще далеко не стареньком Pentium 90. Позже были такие же траблы с какой-то прогой, заточенной под 3dNow.

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

Судя по-всему Кит пишет свою СУБД...

P.S.

Продолжив тему можно вспомнить о том что нейросети очень эффективно реализуются при помощи DSP-чипов. В связи с этим предлагаю обсудить возможность написания ГО-программы в виде особого драйвера к звуковой

Re: Ассемблер x86 против C
orange на rugo.ru Любитель Го
18, May, 2004 03:37   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Мое мнение прямо противоположно мнению автора этой ветки.
Программа го должна играть в го а не бегать на перегонки.
Алгоритм такой программы явно не из простых. Т.е. скорость далеко не самая важная и далеко не самая трудная часть реализации такого алгоритма. Усложнять же себе работу еще и выбором ассемблера это мазохизм. Наоборот, надо выбирать самый высокоуровневой язык из возможных. И единственное в чем я согласен с автором, это то что Си - плохой выбор. Правда совсем по другой причине. Не потому что он слишком высокоуровневый, а потому что он недостаточно высокоуровневый. Я думаю наиболее идеально для решения задачи го подходят функциональные языки (Haskell, Clean)

Re: Ассемблер x86 против C
Владимир на rugo.ru Гость
18, May, 2004 11:12   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Есть язык который и достаточно низкоуровневый и даже очень высокоуровневый - это Форт! Правда к нему нелегко привыкнуть из-за специфической записи программы, но он позволяет и модифицировать свой код и другие экзотичные вещи типа расширения встроенных средств и пользования ими. Недаром автор его создал для управления телескопом. А по скорости он от асма отстает в 1.5-2 раза.

Re: Ассемблер x86 против C
Илья Ветров на rugo.ru Ценитель Го
18, May, 2004 11:48   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

> это Форт!

ААААААААА !!!!!!!!!!!!!!!!!
Нет , сэр , умоляю Вас , все что угодно , только не это , сэр !

А если серьезно , форт - глубоко на любителя . Есть масса языков . Еще больше критериев для их сравнения . И совсем грандиозно число сравнительных статей и обзоров , поэтому незачем начинать заново .

Хронически тлеющий флейм в этом форуме связан не с языками вообще и не с асмом в частности , а с позицией "я ничего не сделал , но ЗАТО я БУДУ делать на асме" . Я сильно подозреваю , что эта позиция притворная , но она конечно раздражает . Ничего не сделал - ну и ладно , у всех свои проблемы , подождем пока другие сделают или попробуем сами . Предпочитаешь мечтать и планировать - прекрасно , вполне возможно , что кто-то подхватит идеи . Любишь асм - люби , кто ж спорит .

Но упомянутая позиция (лучше ничего не делать на асме , чем делать на других языках) означает (кроме прочего) признание дискомфорта и низкой эффективности работы на асме . Если человек выбрал для работы наилучший инструмент , он просто покажет всем , как быстро и успешно продвигается работа благодаря этому инструменту и детально разъяснит , чем хуже был бы другой инструмент для данной работы .



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

Re: Ассемблер x86 против C
Олег Попов на rugo.ru Любитель Го
18, May, 2004 12:30   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

меня поражает упорство, с которым kit144 возрождает этот бесплодный флейм. Ему уже не один десяток раз объяснили, что никто не беспокоится о том, на чём он будет писать свою грандиозную го-программу.

чем больше идёт этот разговор, тем крепче моя уверенность в том, что kit144 никогда и ничего не напишет.

конечно, он ещё много раз напишет нам в форум о прелестях ассемблерного программирования, но программу, которая будет играть в го, он не напишет никогда.


Re: Ассемблер x86 против C
Максим Подоляк на rugo.ru Любитель Го
18, May, 2004 13:06   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Хехе.
Я уже перестал (даже во сне) бурчать "Маздай" и "Alt-F4". Несмотря на готовность, а иногда и необходимость, копаться в форточках, всякий раз после очередного падения терпеливо их поднимаю, отряхиваю им коленки, вытираю им нос и лёгким шлепком отправляю вперёд, к следующему падению.
Наверное, постарел. Честно говоря, иногда в голову залазят шальные мысли про юниксоидности, но я стойко борюсь с собой. Зачем мне, я ведь простой юзер, я даже Оперу не ставлю, потому что мне просто не нужно, а может, потому что лень. Не говоря уже о смене платформы.

Тем не менее, почитать Кита было забавно. Предлагаю вручить ему медаль "За стойкость" (возможно, "За верность"). Когда я практиковал, я тоже всё писал на асме, вплоть до вывода на экран. Причём не через 21Н, а через 10Н. Слава богу, дальше я не пошёл, а то бы и мне пришлось давать медаль :)) а то и орден ;)))



&lt;Китай в нашем сердце&gt;

Re: Ассемблер x86 против C
Илья Ветров на rugo.ru Ценитель Го
18, May, 2004 13:16   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Два хе-хе , Максим . Опера на ассемблер ну ни в чем не похожа ! Скачиваешь 3 мега и пробуешь , интерфейс можно минимизировать до полного аскетизма .

Вот все несем крест - опровергаем аргумент "есть же шахматы , и нафига все эти ваши ..." . А сами ? Ладно , новый язык программирования опробовать трудоемко , но Драгон или Оперу ...

Странно мне с вас . Или с нас ...



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

Re: Ассемблер x86 против C
Олег Попов на rugo.ru Любитель Го
18, May, 2004 13:33   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

ага, думаю, идеальным рисунком такой медали является осёл, как символ стойкости и упорства


Re: Ассемблер x86 против C
kit144 на rugo.ru Любитель Го
18, May, 2004 15:06   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Илья. А ты что у меня был?
Видел как идут дела?
Или же у тебя есть , как в фильмах, система спутникового наблюдения?
Что бы так голословно говорить.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Re: Ассемблер x86 против C
Илья Ветров на rugo.ru Ценитель Го
18, May, 2004 17:16   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

> Илья. А ты что у меня был?
> Видел как идут дела?

Эх , Олег , если бы ты от себя требовал такой же ответственности ...

Специально для ДРУГИХ читателей форума - косвенные сведения о качестве и стадии разработки Кита . За отсутствием прямых . Судя по этим цитатам , конь еще не валялся , но зато твердо и бесповоротно выбрана масть коня , которому предстоит валяться (это я про ассемблер) . Остается загадкой - была ли какая-то недогениальная прога , диктовавшая Киту ходы в Кисейдо ? Добавлю еще - проект Кита начался в начале 2003-го года , он искал в Кисейдо команду для включения в якобы ужЕ идущий проект . Контекст цитат - см. по ссылкам .

================================
[forum.weiqi.ru]

Автор: Илья Ветров
Дата: 14/11/03 11:55

[.......]

Ты упомянул про уравнения Грофмана . Я ничего про них не слышал , но готов допустить , что ты знаешь про них не только имя их автора . Тогда мои обвинения в полном бездействии я снимаю . Ты (кажется за полгода развития твоего проекта) пришел к выводу , что гобан лучше реализовать двумерной матрицей и прочитал что-то про уравнения Грофмана . Главное ведь чтобы самому было интересно , правда ? Ну а то что люди не видят никаких перспектив (даже просто творческих) работы в твоей команде - подумай еще раз , может они правы ? Может нужен какой-то задел от инициатора , а не только вопли , что кто не с тобой , тот ноль в программировании ?

Автор: kit
Дата: 14/11/03 13:11

[.......]

а то что на асме не программят, это выяснили давно уже,
на С/ С++ программа не пойдет, признание многих программистов,
и не только наших Россиийских, но и зарубежных.........

Автор: Олег Попов
Дата: 14/11/03 14:57

ну, тогда скажу чуть иначе:
продукты, которые стоят у значительного большинства людей, смотрящих в экран компика, написаны на С/С++:
-- Все массовые продукты Майкрософт
-- Все продукты Адоба
-- Все продукты Макромедиа
-- Все Юниксы, включаю Линуксы
-- Значительная часть СУБД
... список можно продолжать долго

[.......]

=====================================
[forum.weiqi.ru]

Автор: kit
Дата: 21/11/03 17:19

На основе играющих програм написал игру, играющую.......
по тем стандартным алгоритмам использующем базы игранных партий профессионалов.
но оказалась муть страшная, убил ее.
можете глянуть , если есть желание, как она выиграла у AlgolSPb в учебной игре. мой ник на сервере kgs.kiseido.com - kit144

======================================
[forum.weiqi.ru]

Автор: kit144
Дата: 09/01/04 22:10

[.......]

Классификация.......... и группировка - пока далековато.
В начале думаю построить определения явно связанных камней.

[.......]

=================
[forum.weiqi.ru]

Автор: kit144
Дата: 09/03/04 19:35

тем кто разбирается в асме" посвящается"....)))))

небольшой код проги для работы с массивом -
может есть предложения по улучшению, или исправлению ошибок-

[.......]

; таблица хранения ходов
board dw 18 dup (18 dup (?)) ; массив 19х19 ячеек, в котором хранится цвет камня сходившего

[.......]

Автор: Rianon
Дата: 09/03/04 20:04

[.......]

> board dw 18 dup (18 dup (?)) ; массив 19х19 ячеек, в котором
говорите, 19x19? у меня такое чувство, будто 18х18 :)

[.......]

Автор: kit144
Дата: 09/03/04 20:22

[.......]

Для сведения, отсчёт в языках программирования начинается с 0 (нуля),
а не с 1 (единицы).

[.......]

Автор: Rianon
Дата: 09/03/04 20:47

[.......]

Команда "board dw 18 dup (18 dup (?))" определяет массив 18*18*2 байт, а не 19*19*2;

[.......]

Автор: kit144
Дата: 09/03/04 21:06

[.......]

Ошибку исправил.

[.......]

====================================
[forum.weiqi.ru]

Автор: kit144
Дата: 29/02/04 15:04

[.......]

Надеюсь, что в июле сможем выдать первый пробный "шар".

[.......]

12 лет пытаюсь написать качественную прогу.

[.......]

Автор: shadowjack
Дата: 25/03/04 18:29

В копилку линков:
[www.gnu.org]
документация по бестплатной (и открытой) программе gnugo.

[.......]

Автор: kit144
Дата: 25/03/04 21:16

Шаблонные решения улучшать?
Или свое ноу-хау кода ядра программы им дать?

================================
[forum.weiqi.ru]

Автор: kit144
Дата: 19/04/04 19:29

[.......]

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

[.......]

Автор: kit144
Дата: 23/04/04 13:51

Из форума сделали мусор.

У вас одни слова. напишите на своем любимом языке программу
и потом посмотрим.

Автор: Илья Ветров
Дата: 23/04/04 16:26

[.......]

Еще интереснее его полумифическое программирование игры Го . Он любит экзотические термины как средство критики других программ , причем (имхо) изо всех сил надеясь , что никто его не поймет и не сможет поддержать разговор . Когда он упоминает о конкретике , возникает четкое впечатление , что он вот-вот допишет программу "Hello World" . Но! Какую-то прогу на тему Го он якобы написал и успешно тестировал ее в Кисейдо , делая ходы по ее выбору , а затем полностью уничтожил все исходники этой проги по каким-то туманным соображениям о ее недостаточной гениальности ...



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

Re: Ассемблер x86 против C
orange на rugo.ru Любитель Го
19, May, 2004 00:10   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

>>>Какую-то прогу на тему Го он якобы написал и успешно тестировал ее в Кисейдо , делая ходы по ее выбору , а затем полностью уничтожил все исходники этой проги

Вот и у Жуль Верна так. Во всех произведениях в конце уничтожаются карты, рукописи, острова уходят под воду, гениальные машины самоуничтожаются, пещеры заваливаются... :))

Re: Ассемблер x86 против C
Максим Подоляк на rugo.ru Любитель Го
19, May, 2004 10:54   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Хехе. И подводные лодки тонут навсегда.

Очень понравилось про 18х18. Пропустил оригинал в своё время.

Скорее всего, Кит - это форум-робот, поскольку живой человек не может так ошибаться.

//Для сведения, отсчёт в языках программирования начинается с 0 (нуля),
а не с 1 (единицы).

Удивительно, что роботы проявляют такую желчность.



&lt;Китай в нашем сердце&gt;

Re: Ассемблер x86 против C
Олег Попов на rugo.ru Любитель Го
19, May, 2004 11:45   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Максим Подоляк писал(а):
> Скорее всего, Кит - это форум-робот

Интересное предположение! %)))
Да, и написал его Гришин с целью поддержания активности форума!


Re: Ассемблер x86 против C
Максим Подоляк на rugo.ru Любитель Го
19, May, 2004 11:59   Об авторе Фотографии автора Партии автора Набор Го автора
 +    0     

Не, Гришин ассемблеру не знает. Если это и он, то, похоже, попросил кого-нибудь. :))))



&lt;Китай в нашем сердце&gt;



Извините, только зарегистрированные пользователи могут писать в этом форуме.

  Путь Го       Го-портал       Новости Го



Галерея И — уникальные наборы игры Го Книги по игре Го