<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Wed, 25 Nov 2009 15:04:35 -0800 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/ru-ru/articles/parallel_chess/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Комментарии фид</title>
    <link>http://software.intel.com/ru-ru/articles/parallel_chess/feed/</link>
    <description></description>
    <language>ru-ru</language>
    <item>
      <title>От Alexei Alexandrov (Intel)</title>
      <description><![CDATA[ Вот этот абзац: 

"Для снижения времени, затрачиваемого на перебор, обычно используются альфа-бета отсечения, которые позволяют отсекать целые поддеревья, при этом не влияя на результат. В алгоритме с альфа-бета отсечениями при рекурсивном вызове передаются alpha и beta - нижняя и верхняя границы значений соответственно. Если возвращаемое значение превышает beta, то происходит отсечение, так как это значение уже не может повлиять на результирующую оценку родительского узла."

зачем-то в тексте продублирован... ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32869</link>
      <pubDate>Sat, 17 Oct 2009 14:31:59 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32869</guid>
    </item>
    <item>
      <title>От Alexei Alexandrov (Intel)</title>
      <description><![CDATA[ А вообще, очень интересная работа! ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32870</link>
      <pubDate>Sat, 17 Oct 2009 14:39:59 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32870</guid>
    </item>
    <item>
      <title>От alexander.musman</title>
      <description><![CDATA[ Абзац исправился. Спасибо за комментарии ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32927</link>
      <pubDate>Mon, 19 Oct 2009 08:11:48 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32927</guid>
    </item>
    <item>
      <title>От Roman Sharygin (Intel)</title>
      <description><![CDATA[ "...Активно использовались Intel® Parallel Inspector для проверки корректности и Intel® Parallel Amplifier для профилировки и повышения производительности...", вот этих деталей хочется побольше. Какие были проблемы, как их удалось обнаружить, понять, оптимизировать и оценить, что проблема ушла. ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32930</link>
      <pubDate>Mon, 19 Oct 2009 09:01:04 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-32930</guid>
    </item>
    <item>
      <title>От alexander.musman</title>
      <description><![CDATA[ В основном проблемы можно разделить на 2 основные группы: связанные с корректностью результатов перебора и проблемы производительности. 
 Для проверки корректности программы проводился перебор из набора тестовых позиций, и сравнивались полученные значения оценки для разного количества потоков. Здесь также использовался Inspector.  В текущей версии, например, при доступе к таблице перестановок (общей для всех потоков) не используется синхронизация, и Inspector сообщает что это нехорошо. Но доступ к таблице требуется достаточно часто, и использование здесь синхронизации при доступе замедлит перебор, да и вероятность ошибки маленькая (кстати, есть интересная статья на эту тему http://www.cis.uab.edu/hyatt/hashing.html).
 У первоначальной версии была недостаточная маштабируемость, и одной из проблем было то, что затрачивалось время на ожидание в spin_mutex, как показал Amplifier. 
 Что интересно, было еще 2 "почти одинаковых" проблемы, связаные с тем, что разные потоки используют один ресурс. Они были незаметны на 4-ядерном процессоре, но сразу выявились при запуске на 24-ядерном. В первом случае это было использование одной atomic-переменной разными потоками для подсчета статистики, во втором случае - обращение к таймеру. Здесь наиболее простое решение - реже обращаться к ним. Например, обращение к таймеру для завершения перебора, если заканчивается время на обдумывание хода программой, в моем случае достаточно делать каждый 1000-й раз. ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33023</link>
      <pubDate>Wed, 21 Oct 2009 04:03:36 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33023</guid>
    </item>
    <item>
      <title>От Dmitry Oganezov (Intel)</title>
      <description><![CDATA[ Отличная работа! И замечательная статья. Но есть несколько хитрых вопроса автору.

Александр, поставленная цель - повышение масштабируемости в рамках выбранного алгоритма. А что такое «масштабируемость»? Где, собственно, ее анализ? Я вижу два графика для двух состояний, но не вижу полной картинки.

Судя по графикам, масштабируемость не растет при увеличении количества ядер от 12 до 24-х. Почему? Плохой алгоритм? Плохая архитектура? Плохая библиотека TBB? Недостаток времени? А ведь по идее, если на 12 ядрах программа играет как перворазрядник, то на 24-х она должна играть как КМС, или даже как мастер спорта.  

Наверное, что-то с масштабируемостью не так? :)
 ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33158</link>
      <pubDate>Fri, 23 Oct 2009 03:49:42 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33158</guid>
    </item>
    <item>
      <title>От alexander.musman</title>
      <description><![CDATA[ Дмитрий, спасибо за вопросы!

Действительно, для статьи я "на глаз" выбрал график для одной позиции, который, по моему, лучше других характеризует "полную картинку" (а ситуация, как на 2-м графике, встречается очень редко). Вообще, эксперименты проводились на 300 позициях из набора "WAC Test suite". В принципе, можно было посчитать среднее ускорение по экспериментам, но тогда возникнет вопрос, насколько выбранные позиции характеризуют "среднюю" позицию, встречающуюся в игре. К тому же, даже в выбранном множестве позиций наблюдается существенный разброс (дисперсия) значений. В основном в статьях о подобных алгоритмах используется некоторый набор позиций, и сравниваются результаты на этих позициях.

То, что масштабируемость не растет при увеличении количества ядер от 12 до 24-х, объясняется тем, что последовательный алгоритм выполняет меньше работы, чем параллельный. В параллельном алгоритме мы в некоторый момент времени начинаем обход нескольких поддеревьев из текущей позиции. Теперь, если результат для первого же поддерева приведет к отсечению, то обход остальных поддеревьев - лишняя работа. А если к отсечению приведет обход не первого поддерева, а какого-нибудь из последующих, это может привести к сверхлинейному ускорению (как на 2-м графике). С увеличением количества ядер объем выполняемой лишней работы возрастает.
Есть и накладные расходы, такие как затараты на передачу данных через общую память, которые неизбежно увеличиваются с количеством потоков, но они не так существенны.

>А ведь по идее, если на 12 ядрах программа играет как перворазрядник, то на 24-х она должна играть как КМС, или даже как мастер спорта.
Не совсем так :) . Даже если бы в алгоритме не было "доли последовальных вычислений",  ускорение в 2 раза дало бы углубление поиска в дереве игры на 1 полуход, при условии, что нам достаточно в среднем просмотреть 2 хода из каждой позиции ( в моей программе пока недостаточно:) ), а остальные отсекаются.

 ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33210</link>
      <pubDate>Sat, 24 Oct 2009 06:15:07 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33210</guid>
    </item>
    <item>
      <title>От Dmitry Oganezov (Intel)</title>
      <description><![CDATA[ Значит ли это, что для шахматных программ 12 вычислительных юнитов - предел, дальше которого наращивать вычислительные ресурсы не имеет смысла?

А как же тогда быть с Deep Blue (суммарно  - 544 юнита, правда частота что-то вроде 130Mgz)?  ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33256</link>
      <pubDate>Mon, 26 Oct 2009 02:13:09 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33256</guid>
    </item>
    <item>
      <title>От alexander.musman</title>
      <description><![CDATA[ По результатам проведенных экспериментов, если отсечь случаи с маленьким временем перебора, в среднем при переходе от использования 12 потоков к 24 перебор происходит быстрее в 1.2 раза, т.е. смысл добавлять узлы еще есть, хотя с количеством узлов он "уменьшается".

Из 544 узлов, которые использовались в Deep Blue: 32 узла SMP машины (возможно, дальше увеличивать их количество смысла не было), а остальные 512 - это по две платы с восьмью специализированными шахматными чипами (на каждом из этих 32 узлов), в которых перебор реализован аппаратно. Насколько я понял, эти специализированные чипы не обмениваются между разными SMP-узлами данными об отсечении.

С увеличением количества ядер, в принципе, возможно, такая схема, когда несколько ядер группируются и "подчиняются" ядрам более "высокого уровня" будет эффективнее для таких алгоритмов. Также, возможно, будет выгоднее иметь отдельные хеш-таблицы для этих "групп ядер", выделяемых в алгоритме. 24 ядра еще маловато, чтобы такое организовывать :) ]]></description>
      <link>http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33261</link>
      <pubDate>Mon, 26 Oct 2009 04:28:30 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/ru-ru/articles/parallel_chess/#comment-33261</guid>
    </item>
  </channel></rss>