Здравствуйте, Mystic, Вы писали:

K>>Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?
M>Да никаких не надо, надо выполнить одну ассемблерную команду.

И что в принципе мешает VM сгенерировать как раз эту команду?

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.

M>Насколько я знаю, во всех сильнейших движках используется генератор ходов на основе bitboard. Васик, когда начал писать свою рыбу, первым делом переписал фруктовский движок на битборды. Разве только Fritz их не использует. Сравни по производительности:

M>1) Берем битовый маску пешек.
M>2) Делаем AND с битовой маской всех полей, кроме вертикали "а"
M>3) Сдвигаем битовую маску на 7
M>4) Делаем AND с битой маской фигур соперника

M>И мы получили сразу половину взятий пешками.

M>Аналогично

M>1) Берем битовую маску ладей
M>2) Получаем номер поля idx первой ладьи
M>3) Сдвигаем битовую маску всех фигур на 1 + idx & 0x38, и берем младшие шесть бит результата. Получаем mask
M>4) По таблице получаем все возможные ходы ладьи по горизонтали.

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

Это все понятно. Только накладные расходны на ручную реализацию bsr в данном случае окажутся пренебрежительно малы. А битовые операции и так есть.

Здравствуйте, jedi, Вы писали:

G>>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.

J> Спасибо, рассмешил.
J>Меня вот удивляет откуда такие знатоки всего беруися?

J>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).
J>А Вы, товавищ gandjustas, чем прославились на этом поприще?
Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Mystic, Вы писали:

K>>>Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?
M>>Да никаких не надо, надо выполнить одну ассемблерную команду.

K>И что в принципе мешает VM сгенерировать как раз эту команду?

Это претензия больше к текущему состоянию дел. Принципиальной проблемы добавить некоторую функцию FirstOne, и чтобы VM знала, что эта функция кодируется одной командой нет.

Здравствуйте, gandjustas, Вы писали:

J>>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).
J>>А Вы, товавищ gandjustas, чем прославились на этом поприще?
G>Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?

Поздравляю. Видимо на этом основании Вы сделались абсолютным знатоком во всех без исключениях областях человеческой деятельности.

Здравствуйте, Mystic, Вы писали:
M>А если он содержит ссылки внутри себя? Плюс потеря производительность на дополнительных проверках...
Полагаю, принципиально возможно совместить высокоуровневые возможности с битоковырянием.
Обрати внимание на bitc, возможно, тебе будет интересно.

Здравствуйте, jedi, Вы писали:

J>Здравствуйте, gandjustas, Вы писали:

J>>>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).
J>>>А Вы, товавищ gandjustas, чем прославились на этом поприще?
G>>Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?

J>Поздравляю. Видимо на этом основании Вы сделались абсолютным знатоком во всех без исключениях областях человеческой деятельности.
Естественно, а как же иначе.

Здравствуйте, gandjustas, Вы писали:

G>Это все понятно. Только накладные расходны на ручную реализацию bsr в данном случае окажутся пренебрежительно малы. А битовые операции и так есть.

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

На счет "пренебрежимо мало"... 64-битный bsf выполняется за 9 тактов. При генерации ходов FirstOne и LastOne вызывается довольно-таки часто. В целом я слышал цифру порядка единиц процентов по сравнению с тем волшебным кодом, что я приводил.

Здравствуйте, WolfHound, Вы писали:

ГВ>>Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.
WH>Ни тот и ни другой.
WH>У них система типов мягко говоря слабовата.
WH>В ядре ОС без зависимых типов делать нечего.

Ну тогда у нас все уже есть — это obj-файлы.

Мне вообще JVM и .Net кажутся временным финтом несколько в сторону из-за слабости возможностей последних.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, thesz, Вы писали:

---------------------------
G>>>>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
T>>>>На 99%.
T>>>>Один процент на то, что потребуется ассемблер. А он потребуется.
G>>>Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.
---------------------------

T>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.
T>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?

Оптимизированный код? Самотестирование?

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

Потому, что низкий уровень бывает разный.

Ты, например, как много "низкого уровня" написал за свою жизнь?

T>>Что-то у меня двойственное впечатление складывается от твоих вопросов. Похоже, тебя интересует не чьё-то мнение, а исключительно своё.
T>>Вот этот вопрос, вопрос про типы

Автор: gandjustas
Дата: 19.06.09

в ветке про TDD. Везде сценарий один и тот же: "x?", мой "y." и твой "а нифига, всё равно x." Без каких-либо признаков даже поверхностных размышлений.
G>Я вроде написал что "есть вероятность", а не то что я "стопудово уверен, а кто не согласен идут в жопу"

Я там выше выделил заинтересовавший меня кусок диалога.

Здравствуйте, thesz, Вы писали:

T>>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.
T>>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?
T>Оптимизированный код?
Погагаю что к тому времени оптимизация для одного процессора отомрет как класс.

T>Самотестирование?
Самотестирования без ассемблера невозможно? Или что-то конкретное имеется ввиду?

T>Потому, что низкий уровень бывает разный.
T>Ты, например, как много "низкого уровня" написал за свою жизнь?
Немеряно, хотя низкий уровень бывает разный

Здравствуйте, thesz, Вы писали:

T>Ты говоришь о полном и безоговорочном доказательстве всего на свете.
T>В этом случае, конечно, нативный код отомрёт.

Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло. На машинах потребительского класса подобные сбои происходят постоянно.

Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, thesz, Вы писали:

T>>Ты говоришь о полном и безоговорочном доказательстве всего на свете.
T>>В этом случае, конечно, нативный код отомрёт.

V>Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло.
А если этот процесс в ядре, то будет синий экран. Тоже самое для плоской памяти. Попадет ошибка на ядро — смерть и перезагрузка, попадет на другой процесс — умрет процесс с CoreCorruptedException или станет неправильно работать.
Сбои ведь происходят в физической памяти, а не в виртуальной.
Кстати при микроядерной архитектуре гораздо меньше вероятность завалить всю систему такой ошибкой.

V>На машинах потребительского класса подобные сбои происходят постоянно.
А есть статистические данные? Сколько ошибок в секунду\час\год на средней машине?

V>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.
Уже сейчас для .NET есть ngen, который позволяет jit-ить сборки при установке, хотя это не всегда выгодно, зачастую jit в рантайме может оптимизировать лучше.
С другой стороны у ngen время работы не сильно ограничено, поэтому он вполне может делать довольно серьезные оптимизации.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, thesz, Вы писали:

T>>>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.
T>>>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?
T>>Оптимизированный код?
G>Погагаю что к тому времени оптимизация для одного процессора отомрет как класс.

"Жаль только, жить в этом мире прекрасном,
Уж не придётся ни мне, ни тебе."

Или как там у поэта.

Юникс уж переносили-переносили, да так без ассемблера и не обошлись. А уж суперкомпьютеры без ассемблера вообще никуда.

T>>Самотестирование?
G>Самотестирования без ассемблера невозможно? Или что-то конкретное имеется ввиду?

Ну, проверь регистры процессора без ассемблера.

T>>Потому, что низкий уровень бывает разный.
T>>Ты, например, как много "низкого уровня" написал за свою жизнь?
G>Немеряно, хотя низкий уровень бывает разный

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, thesz, Вы писали:

T>>Ты говоришь о полном и безоговорочном доказательстве всего на свете.
T>>В этом случае, конечно, нативный код отомрёт.
V>Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло. На машинах потребительского класса подобные сбои происходят постоянно.

Последнее, конечно, преувеличение, но согласен.

V>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.

И тут не могу не согласиться.

T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
WH>Так и запишем.

Вдогонку.

TLB обеспечивает 99%+ попаданий. 64 удреса страницы * 4KБайт на страницу — 256КБайт. Итого, на одно обращение расход времени из-за TLB у MIPS с его 40 тактами < 0.4 такта.

При промахе в L1 кэш задержка в ~5-15 тактов. Размеры L1 << размеры памяти, покрываемой TLB. L1 кэш менее эффективен.

Иными словами, ты можешь устранить TLB, но тогда тебе придётся делать что-то наподобие Fault-tolerant typed assembly language для защиты от кратковременных сбоев. А для его нормальной работы требуется суперскалярность и регистровый файл побольше, что не отставать от обычной железки. Кстати, расходы у FTTAL примерно в районе 30%.

Запиши эти новые факты и подумай снова.

Здравствуйте, thesz, Вы писали:

T>Юникс уж переносили-переносили, да так без ассемблера и не обошлись.

T>Ну, проверь регистры процессора без ассемблера.

Что касается разработки ядра ОС, то там в любом случае будет нативный и ассмеблерный код.

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

T>А уж суперкомпьютеры без ассемблера вообще никуда.

T>>А уж суперкомпьютеры без ассемблера вообще никуда.
G>

Именно-именно.

Здравствуйте, gandjustas, Вы писали:

G>Сбои ведь происходят в физической памяти, а не в виртуальной.

Смотря какой код/данные пострадали: пользовательские или ядерные.


G>Кстати при микроядерной архитектуре гораздо меньше вероятность завалить всю систему такой ошибкой.

Пофиг вид архитектуры, если "зараженному" коду видна вся плоская память.

V>>На машинах потребительского класса подобные сбои происходят постоянно.
G>А есть статистические данные? Сколько ошибок в секунду\час\год на средней машине?

У меня еще не было компа, чтобы он в нашей жаре летом не сбоил хотя бы раз в неделю.


V>>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.
G>Уже сейчас для .NET есть ngen, который позволяет jit-ить сборки при установке, хотя это не всегда выгодно, зачастую jit в рантайме может оптимизировать лучше.

Это проблемы ngen-а, а не здравого смысла.

G>С другой стороны у ngen время работы не сильно ограничено, поэтому он вполне может делать довольно серьезные оптимизации.

Именно, но инфраструктуры вокруг ngen никакой пока мест. Деплоить выгодней в "объектном" формате, т.к. он более переносим и краток, но запускать надо уже нативный, и как правильно было замечено — хорошо оптимизированный код. Сейчас такой сценарий в общем случае недостижим при использовании того же Click-Once.

Здравствуйте, WolfHound, Вы писали:


C>>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
B>>Осталось его весь верифицировать
WH>Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются.
WH>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

Ну вот С++ на зависимых типах построен, однако через Си-касты и прочие xxx_cast<> все это обходится легко. Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное".