В своей записи на здешней блог-площадке Вячеслав Любченко привёл графики времени работы параллельного рекурсивного алгоритма нахождения чисел Фибоначчи в зависимости от порядкового номера числа в последовательности. И в случае реализации алгоритма на TBB время росло экспоненциально, а у реализации, где структура алгоритма описана при помощи конечных автоматов (КА) - линейно!

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

Исполнение рекурсивного алгоритма определения числа Фибоначчи суть есть обход двоичного дерева с подсчётом его листьев. Последовательное исполнение - обход в глубину, параллельное - обход в ширину. Глубина дерева - N-1, где N - порядковый номер искомого числа Фибоначчи (рассматриваем N>1, считая, что для N<=1 решение известно). Для идеально сбалансированного двоичного дерева на каждом ярусе глубины d содержится 2 в степени d (2^d) узлов; соответственно, количество листьев - 2^(N-1). В нашей задаче дерево не сбалансировано; но можно показать, что и в нашем случае максимальное количество узлов на одном ярусе, как и общее количество узлов, имеет асимптотическую оценку O(2^N). 

В КА реализации у Вячеслава каждому узлу дерева соответствует один конечный автомат, а в самой простой реализации на TBB - одна "задача", то есть объект класса, унаследованного от tbb::task. Все автоматы, как и все задачи, могут работать/исполняться независимо друг от друга. Так откуда же разница в поведении?

А разница, на самом деле, в применённых методиках измерения. При оценке поведения КА реализации Вячеслав использовал дискретное время. За один такт дискретного времени все автоматы осуществляют переход из одного состояния в другое, причём их количество на дискретное время не влияет. По сути, время оценивается до этапа отображения (mapping) возможного параллелизма на конкретную аппаратную платформу.

При получении же графиков для TBB и MC# использовалось время "настенное" (wall clock time), измеренное после отображения возможного параллелизма на реальную платформу, в которой фактическая степень параллелизма равна 2 и постоянна. Чуда не случится, от добавления второго (4-го, 32-го) ядра асимптотическое поведение алгоритма не изменится.

Чтобы поведение алгоритма, предсказанное в дискретном времени, совпадало с поведением во времени реальном, необходима такая же степень реального (аппаратного) параллелизма, какова была степень параллелизма при получении оценки. То есть, для достижения асимптотического поведения О(N) необходим аппаратный параллелизм порядка O(2^N). Подумаешь, всего какой-то миллион или около того ядер для вычисления 30-го числа Фибоначчи Причём, если зафиксировать аппаратный параллелизм даже на этом уровне и продолжить увеличивать N, то асимптотическое поведение быстро вернётся к экспоненциальному; для сохранения линейности алгоритма необходимо и дальше экспоненциально наращивать мощность. Представьте себе компьютер, в котором сколь угодно много вычислителей добавляются динамически по мере надобности и сразу же встраиваются в работу программы. Это, конечно, классно, но боюсь, ещё долго останется нереальным.

Чтобы избежать сравнения яблок с томатами, можно для КА реализации алгоритма построить график зависимости реального времени от N. Поскольку переходы для всех автоматов обсчитываются последовательно на одном ядре, реальное время, соответствующее одному дискретному такту, будет сильно разным для моделей из десятка и из миллиона автоматов, а в результате на графике будет та же экспонента (что Вячеслав и подтвердил в комментариях).

Справедливости ради замечу, что Вячеслав предпринял попытку привести измеренное реальное время в форму, пригодную для сравнения с дискретным. Но это, на мой взгляд, невозможно. Его идея об использовании времени работы итеративного алгоритма в качестве нормирующего фактора явно не работает. Докажу от противного: если такое преобразование приводит реальное время в форму, сопоставимую с дискретным, то это должно быть истинно и для КА модели. Реальное время T работы КА программы растёт как O(2^N), при нормировании константой получим время T'=T*O(1), то есть растущее по тому же закону. Соответствия поведению дискретного времени DT ~ О(N) мы не получили, значит, преобразование не достигает желаемой цели.

Стало быть, выводы, которые Вячеслав сделал о TBB как параллельной модели, некорректны, так как исходили из ложных посылок.

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

Наши же игроделы представлены архискромно. Стендов, как таковых, нет ни у кого - даже у великой 1С. Так, тематические инсталляции с мониторчиками. Кризис, скажете? Он самый, только вы даже не представляете - насколько серьезно он затронул наших игроделов. Один знающий человек сказал мне, что у самой крупной на нашем рынке компании (простите, не могу сказать точнее) продажи упали... нет, не в два раза. Не в четыре. Не в десять. В ПЯТЬДЕСЯТ раз. Мне самому не верится в такие цифры, однако не доверять источнику нет ни единой причины. Если для западного издателя такое падение еще как-то переносимо за счет внутреннего жирка, то для наших... Мда.

Есть мнение, что к следующей осени мы рискуем не досчитаться не только "Игромира", но и пары-тройки отечественных производителей игр, которых и так немного. Хорошо это или плохо? Трудно сказать. С одной стороны, хороших российских игр и в лучшие годы было мало, а покупать шлак из чувства патриотизма почему-то не хотелось. С другой, какую-никакую, но рыночную нишу ПОТОМ вернуть назад будет почти невозможно. Да и тренироваться на кошечках начинающим российским программистам станет негде...

А пока музыка еще играет, сходите на "Игромир"! Завтра и послезавтра там обещают быть всякие конкурсы с призами, а еще на стендах можно будет встретить Джо Кукана, сыгравшего негодяя Кейна в сериале Command&Conquer, а также Дмитрия Юрьевича Пучкова АКА Goblin. Ценная наводка: Кейн будет завтра не раньше второй половины дня, тогда как Д.Ю. планирует отработать с утра до вечера.

Я может быть тоже в субботу еще разок съезжу. Многие недели и месяцы, проведенные в мире C&C, стучат в моем сердце.

Но – к делу! Если доверять классикам, то иногда нужно сделать шаг назад, чтобы потом - два шага вперед. А что же в параллельном программировании? Куда мы шагаем, что и в чем выигрываем? Чтобы легче было шагать, нам в помощь дадены разнообразные средства для параллельного программирования – языки, библиотеки и т.п. Обратим свой взгляд на библиотеку Intel® TBB (Intel® Threading Building Blocks) и посмотрим, куда она нас приведет. Будет ли наш «параллельный путь» легче и/или быстрее.

Собираясь в дальний путь, настоятельно рекомендуется проверить средства передвижения. В противном случае – это халатность, граничащая с безрассудством. Целям проверки в дистрибутиве TBB служат ее тестовые примеры. Выберем из множества примеров, имеющихся в составе дистрибутива, один из самых простых и наглядных – вычисление чисел Фибоначчи. Это проект fibonacci из дистрибутива TBB.

Числа Фибоначчи нам известны, или должны быть известны, с юных лет (см., например, «Энциклопедический словарь юного математика»). Результаты тестовых прогонов для чисел в диапазоне от 20-го до 28-го числа по обычным алгоритмам – императивному и рекурсивному и параллельному аналогу рекурсивного алгоритма сведены в таблицу 1.

Таблица 1.
20 21 22 23 24 25 26 27 28
0,002033 0,002187 0,002333 0,002502 0,002678 0,00282 0,002978 0,003184 0,003376
0,5717 0,9314 1,499674 2,427057 3,948402 6,3763 10,30745 16,63595 26,99721
38,277 61,795 100,736 162,243 264,04 427,75 691,78 1119,94 1808,8
19,626 32,397 50,981 82,236 132,24 214,11 344,99 557,68 903,44

В ней первая строка соответствует номеру числа, вторая - реальному времени работы императивного алгоритма, третья - рекурсивного, четвертая и пятая – однопоточной и двухпоточной версиям рекурсивного алгоритма на базе TBB. Рекурсивный алгоритм заимствован из документа Tutoril комплекта документации к TBB, используемый процессор - Intel® Core™2 CPU 6400 @ 2,13 GHz.

Поскольку тестирование проводилось на двухядерном процессоре, то время работы «двухядерного» варианта меньше ровно в два раза. Эффект от многоядерности налицо! Однако, если мы сравним время работы алгоритмов во второй строке и в четвертой, то имеем замедление работы более чем в тридцать три раза (на первую строку лучше не смотреть!). Или, другими словами, чтобы достичь скорости исходного алгоритма, запрограммированного обычным способом и на одном ядре, нам нужно будет минимум шестьдесят шесть (!) ядер, чтобы хотя бы приблизиться к нему по производительности. Глядя на таблицу и вспоминая вопрос Сергея Вильянова – «Есть ли реальная польза от многоядерных процессоров?», напрашивается один ответ – нет, т.к. медленно!

При такой скорости многоядерности сложно быть «торопливым» (см. http://software.intel.com/ru-ru/blogs/2009/02/12/2000639/). Мечталось-то, ведь, совсем о другом! Но если серьезно, то подобные факты не способствуют оптимизму, т.к. желаемое и в этот раз только отодвинулось, причем на достаточно большое расстояние, т.к. о более чем шестидесятиядерном процессоре сейчас, думаю, даже мечтать нельзя, хотя и ходят разговоры о тысячах ядер!

Но проблема-то, как это ни удивительно, не в скорости. Скорость - это как раз поправимо. Проблема глубже. Если мы немного «пошаманим» с таблицей, то вдруг выясняется, что параллелизма как такового библиотека TBB в приложение не добавляет. Скрытое становится явным, если мы посмотрим на графики алгоритмов, которые приведены к времени вычисления императивного алгоритма (к вычислению 20-го числа).

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

Рис.1. График зависимости скорости работы программы от n

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

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

Весьма важное замечание. Сейчас мы в поиске надежных, эффективных и адекватных средств и/или моделей параллельных вычислений. В этом смысле параллельный рекурсивный алгоритм оказался «лакмусовой бумажкой» тестирования библиотеки на адекватность параллелизму. Пока, как показало испытание, несмотря на заявленный параллелизм, ТВВ не влияет качественно на свойства алгоритма (скажем осторожно – в данном случае). Да, отдавая ей должное, TBB использует множество ядер (см. таблицу 1), но при этом не добавляет параллельных свойств алгоритму. Что делать? Это уже вопрос, наверное, к … Алексею. Если, конечно, он не отмолчится в очередной раз

И еще. Сороковое число обычный рекурсивный алгоритм считает почти за 9 сек, параллельный двухпоточный – за 290 сек! Все то же сакральное - «тридцать три». Параллелизм – полный!

А интересно, какую зависимость получим, протестировав параллельный рекурсивный алгоритм на MC#? Этого я, честно, пока не знаю. Вот выяснением этого и займусь. Проблема только в одном – мне известно, что уже на 16-м/17-м числе программа на MC# аварийно завершает свою работу. Значит, нужно выбирать другой диапазон…

Несколько лет назад в 2007 году руководитель подразделения Microsoft Windows Server Бил Лейнг заявил: "Windows Server 2008 будет последней 32-битной операционной системой. Все будущие версии операционных систем для серверов от Microsoft после Windows Server 2008 будут 64-битными". Тогда мы вывесили эту цитату на страницу продукта Viva64 и, надеемся, она стимулировала разработчиков программ делать 64-битные версии своих приложений.

Операционная система Windows Server 2008, выпущенная в феврале 2008 года, была представлена в 32-битном и в 64-битном вариантах.

Рисунок 1 - Логотип Windows Server 2008

Однако выпущенная в июле 2009 года следующая версия Windows Server 2008 R2 доступна только в 64-битном варианте!

Рисунок 2 - Логотип Windows Server 2008

Похоже, что действительно больше 32-битных серверных операционных систем от Microsoft мы не увидим. И это понятно, ведь без 32-битной версии системы затраты на поддержку для Microsoft (со временем) сократятся.

Однако на остановке выпусков 32-битной версии системы Microsoft не остановилась.

Многие администраторы знают про относительно новый режим установки и работы серверной версии операционной системы под названием Server Core.

Рисунок 3 - Установка в режиме Server Core

Это тот режим, о котором участники войн "Windows vs Linux" говорили очень давно. Одним из аргументов сторонников использования Linux на сервере была возможность установить серверную ОС без графического интерфейса (GUI). Но вот и в Windows Server появилась такая возможность. Установка в этом режиме позволяет получить только командную строку без пользовательского интерфейса.

Эта возможность (установка Server Core) появилась в Windows Server 2008. Но в Windows Server 2008 R2 появилось нововведение, приближающее 64-битное будущее. При установке Windows Server 2008 R2 (Server Core) поддержка запуска 32-битных приложений стала опциональной! Причем по умолчанию эта поддержка выключена. И при попытке запуска 32-битного приложения в режиме Server Core, пользователь получит сообщение о невозможности запуска. Конечно, можно добавить поддержку 32-битных программ:

start /w ocsetup ServerCore-WOW64

В обычном (Full Installation) режиме 32-битные приложения по умолчанию запускаются, а вот в Server Core - уже нет.

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

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

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

Итак после краткого введения в специфику решаемых задач рассмотрим результаты одного вычислительного эксперимента решения задачи коммивояжёра на МВС-100К:

В столбце "Ускорение" задано ускорение по сравнению с последовательным (однопроцессорном) вариантом. Как легко заметить, практически во всех строках мы наблюдаем сверхлинейное ускорение, кроме строки с числом процессоров равным 32. Мало того, здесь наблюдается еще одна интересная аномалия: задача на 4-х процессорах решается быстрее, чем на 8. Объяснение этой аналомалии мне уже приходилось давать:

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

В цитате еще раз напоминается о важности хорошего рекорда. Похоже, что в варианте с 4 процессорами кости легли так, что хороший рекорд очень быстро находится. В этом легко убедиться посмотрев на столбец "Число ветвлений". В варианте с 4 процессорами ветвлений меньше миллиона, в то время как в варианте с 8 процессорами их почти 2 миллиона.

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

Мы можем видеть, что ни о каком сверхлинейном ускорении и речи быть не может.

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

class CWinApp {
  ...
  virtual void WinHelp(DWORD dwData, UINT nCmd);
};

Для показа собственной справки в пользовательском приложении необходимо было эту функцию перекрыть:

class CSampleApp : public CWinApp {
  ...
  virtual void WinHelp(DWORD dwData, UINT nCmd);
};

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

class CWinApp {
  ...
  virtual void WinHelp(DWORD_PTR dwData, UINT nCmd);
};

В 32-битном режиме типы DWORD_PTR и DWORD совпадали, а вот в 64-битном... Естественно разработчики пользовательского приложения тоже должны были сменить тип на DWORD_PTR для корректной перегрузки, но компилятор про это не говорил, и ошибка выявлялась только на этапе тестирования, когда справочная система вела себя "загадочно". За подробностями я отсылаю читателя к упомянутой выше статье.

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

Есть прекрасная библиотека компонентов BCGControlBar. Наверняка вы про нее слышали, поскольку компоненты компании BCGSoft Ltd включены в Microsoft Visual Studio 2008 Feature Pack. Так вот, если скачать ознакомительную версию этой библиотеки, установить ее и выполнить поиск слова "WinHelp" по .h-файлам... то мы увидим, что везде, где якобы перекрыта эта функция, используется параметр DWORD, вместо DWORD_PTR. А это означает, что справка в 64-битной системе в этих классах будет вести себя некорректно.

Неужели подобная ошибка может до сих пор быть в коде такой известной библиотеки? Я думаю дело в том, что клиентам компании доступны исходные коды этой библиотеки и клиенты всегда могут поправить эти коды. Кроме того, в настоящее время функция WinHelp используется очень редко. Намного чаще используется HtmlHelp. А она-то в BCGControlBar имеет правильный параметр DWORD_PTR. Однако факт остается фактом. Ошибка есть во вполне реальном коде и компилятор ее не обнаружит.

Что делать? Использовать специализированные анализаторы кода. Например, PVS-Studio. Ведь этот анализатор с момента своего создания умеет находить такие ошибки, а справочная система содержит подробный пример (смотрите описание ошибки V301).

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

А что еще в виртуальность перетаскивается?

Например, мощная видеокарта – кому она нужна в компьютере? Пусть производитель хранит все текстуры игры у себя на сервере, и там же обсчитывает картинку, а на компьютер пользователю отправляет только готовый результат. Поправьте меня, но для такого варианта не нужно запредельно скоростное интернет-соединение. 60-70 мегабит должно хватить даже для хорошего шутера на приличном мониторе, а уж про всякие аркадки и стратегии и говорить не приходится. В Японии это норма уже сегодня, а значит лет через пять и мы догоним.

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

Данные? Ну, конечно, даже 100-мегабитный удаленный винчестер вряд ли кого-то порадует, однако значительная часть файлов поддается неслабому сжатию, что в сочетании с небольшими размерами этих самых файлов может сделать виртуальный накопитель весьма интересным решением. Например, файлы до 10 мегабайт включительно система по умолчанию будет сохранять где-то в онлайне, а те, что побольше – на компьютере. За скорость доступа к файлам тоже переживать не стоит – вспомним о технологии ReadyBoost и ценах на флэшки. В 8-гигабайтном USB-стике (800-900 рублей) уместятся все часто используемые приложения и файлы для мгновенного доступа, тогда как остальное может спокойно подкачиваться из Сети.

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

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

Перед тем, как привести пример работы технологии, придется рассказать о недавно добавленной поддержке замыканий в C/C++/Objective-C под называнием "блоки". Блоки объявляются с помощью нового оператора ^:

int i = 5;
testb = ^(char *s) { printf("string is %s, number is %d\n", s, i); };
testb("hello");

Результатом вызова в 3-й строке будет:

string is hello, number is 5

Подробнее о блоках мы можете почитать в википедии: Блоки (расширение языка Си).

Итак, на входе у нас имеется следующий последовательный код:

for (i = 0; i < count; i++) {
      results[i] = do_work(data, i);
}
total = summarize(results, count);

При условии, что функция do_work не изменяет какие-либо глобальные переменные, мы можем распараллелить с помощью OpenMP:

#pragma omp parallel for
for (i = 0; i < count; i++) {
      results[i] = do_work(data, i);
}
total = summarize(results, count);

А при использовании GDC код будет выглядеть так:

dispatch_apply(count, dispatch_get_global_queue(0, 0), ^(size_t i){
     results[i] = do_work(data, i);
    });
total = summarize(results, count);

Почувствуйте, что называется разницу. На самом деле разница, конечно, есть. Технология Apple имеет более широкое применение, к примеру, задачи мы можем запускать не только параллельно, но и асинхронно (dispatch_async), а также запускать в определенное время (dyspatch_after). Таким образом, GDC поддерживает не только параллельные вычисления, но обеспечивает новый способ добавления асинхронности в приложения. Притом этот способ действительно выглядит весьма прозрачным и простым, как утверждает Apple. Мало того, Apple обещает, что создание и запуск задачи будет требовать очень мало ресурсов, намного меньшие чем создание и запуск потока.

В целом, Grand Central Dispatch выглядит неплохо, предлагает новый подход к созданию параллельных приложений и асинхронных вызовов (хотя концепция задачи отнюдь не нова, она давно витает в воздухе), но на революцию совсем не тянет. Т. к. основная задача распараллеливания - выделение независимых участков кода, которые могут выполняться параллельно, все равно остается на разработчике.

Что интересно, Apple выпустила GCD под открытой лицензией Apache, и в данный момент эта технология уже портирована на FreeBSD (см. [1]).

Ссылки:

1. libdispatch
2. Wikipedia: Grand Central Dispatch
3. Wikipedia: Блоки (расширение языка Си)
4. Поддержка замыканий в Snow Leopard

P.S. По этой теме я перевел 2 статьи англоязычной википедии про GCD и Blocks, и понятное дело, разместил их перевод в русской википедии. В ходе перевода пришлось сделать ряд допущений, к примеру, Blocks перевел как блоки, а Task Parallelism - параллелизм задач (есть вариант параллелизм заданий). В общем, я усиленно намекаю что, критика перевода и особенно его улучшение приветствуются.

Для знакомства с оператором new, не генерирующем исключений я отсылаю вас к статье "Nothrow new". А здесь просто приведу два примера, который достаточно ясно продемонстрируют общую идею.

Код с обработкой исключения:

size_t errCount = 0;
#pragma omp parallel for num_threads(4) reduction(+: errCount)
for(int i = 0; i < 4; i++)
{
  try {
    float *ptr = new float[10000];
    // code
    delete [] ptr;
  }
  catch (std::bad_alloc &)
  {
    ++errCount;
  }
}

Упрощенный код без обработки исключений:

size_t errCount = 0;
#pragma omp parallel for num_threads(4) reduction(+: errCount)
for(int i = 0; i < 4; i++)
{
  float *ptr = new(std::nothrow) float[10000];
  if (ptr == NULL) {
    ++errCount;
  } else {
    // code
    delete [] ptr;
  }
}

Тематика блога вряд ли будет отличаться от моих интересов: технологии параллельных вычислений MPI, OpenMP, CUDA, PThreads и пр.

То, что за параллельными вычислениями будущее - оно, конечно так. Это еще наши дедушки смогли понять, когда осознали, что процессор в 1 гигагерц им и за миллиард полновесных рублей не продадут, а вот 1000 процессоров по 1 мегагерцу - за милое дело.

А уж в современном мире, где тактовая частота процессоров плавает где-то около своего  технологического предела, и основным направлением в развитии процессоров стало повышение количества ядер, выбора особого и не остается. И вот гром грянул раз, когда вышли 2-ядерные процессоры, грянул два, когда появились 4-ядерные, а теперь он грозится долбануть в третий раз. Но мировой разработчик не особо и чешется. Почему?

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

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