Теоретически если бы нейросети были натренированы лучше, то необходимое количество ресурсов становится радикально меньше. Весь вопрос — можно ли лучше натренировать? Никаких теоретических оценок или ограничений нет, в других задачах получается находить архитектуры и решения все точнее и точнее.
Глядишь и тут будет прогресс.
В некотором смысле, где есть feature engineering, там есть и expert knowledge. Часть системы — линейный классификатор на основе заранее заданных фич, что попадает в эту категорию. Возможно, если есть какие-то еще инсайты, можно добавить их к оценке нода.
Но все равно похоже они должны быть заданы так, чтобы модель можно было обучать. Иначе не получится адаптировать это для стратегии, которая эволюционирует через reinforcement learning.
В некотором смысле да, но я уточню.
Так как вероятность просмотра напрямую зависит от того, какой у позиции Q-score (симуляция выбирает ходы с максимумом Q + m(P)), то он очень коррелирует с тем, насколько выгодны позиции дерева за ним. Теоретически, можно выбирать и по максимуму Q-score напрямую, но вот они обнаружили, что по количеству чуть стабильнее.
У них в финальной версии даже есть эвристика, что если эти две метрики не сочетаются, надо прогнать дополнительные симуляции.
www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
Выглядит неплохом руководством. Вкратце, надо добавить код, который по unhandled exception создает файл с минидампом. Этот дамп потом можно открыть на другой машине и посмотреть на состояние регистров и памяти в момент падения. В коде, который создает Minidump можно подкрутить опции, чтобы он делал полный дамп памяти процесса. Понятное дело, нужны символы того билда, в котором упало.
В Advanced Windows Debugging (http://advancedwindowsdebugging.com/) есть целая глава про postmortem debugging, это довольно полное описание всех возможностей. Ее довольно тяжело читать, но оно того стоит.
Хотя Брукс и написан черти когда, на практике вменяемо устроенных Design Review я мало где видел. Видел, что не делают никак. Видел, что говорят ни о чем. Видел ту самую безответственность.
Так что я хотел скорее за свою практику и опыт написать, чем книжки пересказывать. У Дэвида просто очень емко выражено.
Холивора не видел. Что все зависит от требований и не всегда производительность приоритет — ну, в десятитысячный повторять не хочется, понимание читателя подразумевается.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
Я готов и всегда рад разговаривать о вкусе устриц с кем-то, кто их давно и долго кушает. Где-то высказывались мнения людьми, лет 5 разрабатывающими под консоли?..
Очень большой кеш — прямое следствие latency памяти. Уверенно пребывать в иллюзии быстрого доступа к памяти можно только если есть уверенность, что твой working set полностью в кеш влезает. Это вряд ли. Но большой кеш сглаживает степень падения, конечно :)
FFT кстати отлично переписывается на регулярные доступы. Матричное умножение отдельными локальными блоками порядка размера кеша.
Вот тут показательный пример — lwn.net/Articles/255364/
Два кеш-мисса — это значит out of order должен предоставить инструкций на 400 тактов, то есть сотни. Это очень немало, их вполне может не найтись.
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
Все, как всегда, сложно. Процессорам на открытах платформах с обратной совместимостью — боюсь, придется играть в эти игры. Потому что а) людям не хочется шибко много думать, когда они пишут код и б) есть очень много уже написанного кода, который хочется запускать быстрее.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
Дык нет же. Раньше было совсем не так, вычисления были сравнимы с доступом в память. Ну комон, если раньше люди для того чтобы программа работала быстрее чаще пытались делать на сложение меньше, то теперь надо смотреть и думать о локальности памяти. Когда скорость доступа к памяти сравнима с обычной инструкций — вообще проблемы локальности не стоит.
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».
Глядишь и тут будет прогресс.
Но все равно похоже они должны быть заданы так, чтобы модель можно было обучать. Иначе не получится адаптировать это для стратегии, которая эволюционирует через reinforcement learning.
Так как вероятность просмотра напрямую зависит от того, какой у позиции Q-score (симуляция выбирает ходы с максимумом Q + m(P)), то он очень коррелирует с тем, насколько выгодны позиции дерева за ним. Теоретически, можно выбирать и по максимуму Q-score напрямую, но вот они обнаружили, что по количеству чуть стабильнее.
У них в финальной версии даже есть эвристика, что если эти две метрики не сочетаются, надо прогнать дополнительные симуляции.
Олдсукл, хардкор и бескомпромиссная уютность!
Выглядит неплохом руководством. Вкратце, надо добавить код, который по unhandled exception создает файл с минидампом. Этот дамп потом можно открыть на другой машине и посмотреть на состояние регистров и памяти в момент падения. В коде, который создает Minidump можно подкрутить опции, чтобы он делал полный дамп памяти процесса. Понятное дело, нужны символы того билда, в котором упало.
В Advanced Windows Debugging (http://advancedwindowsdebugging.com/) есть целая глава про postmortem debugging, это довольно полное описание всех возможностей. Ее довольно тяжело читать, но оно того стоит.
Спрашивай, если что.
Так что я хотел скорее за свою практику и опыт написать, чем книжки пересказывать. У Дэвида просто очень емко выражено.
Видимо, я очень не привык к употреблению слова «архитектор» применительно к разработке и поэтому пытаюсь придумать термин.
Но видимо общеупотребимо уже, раз так — мне не жалко :)
Спасибо.
Нет уж, нет уж, я нашел свой компромисс.
Тема низкоуровневой оптимизации как таковой — слишком широка, чтобы ее объять одним постом. Или даже книгой, или даже жизнью одного человека. Саттер вот про Memory Latency выступил, Ульрих написал монументальный труд про память как таковую.
Поэтому я не очень понимаю, как можно целиком тему производительности раскрыть.
Вот тут показательный пример — lwn.net/Articles/255364/
На самом деле, Hyper-Threading не в последнюю очередь был придуман затем, чтобы сглаживать такие простои. Пока один тред ждет на доступе к памяти, другой может выполняться. Но даже двух тредов мало, когда оба начинают генерировать стабильные кеш-миссы.
Действительно «прогрессивные» в этом плане скорее Cell и Larrabee.
А вот когда она есть — тогда надо делать и out of order, и кешировать, и префетчить, и выбирать структуры данных.
Мне кажется, если честно, у нас какое-то номиналистическое непонимание. Вы утверждаете «скорость доступа к памяти не увеличилась, ничего не поменялось». Я утверждаю «но на все остальное действовал закон Мура, и поэтому вес этого фактора принципиально возрос».