Введение
В первом репортаже с московского Форума Intel для разработчиков мы рассказали подробности доклада Патрика Гелсингера, а также представили интересные новинки компании Kraftway. Второй репортаж посвящён разработке многопоточных приложений, технологии Wireless USB и автомобильным гонкам DARPA Grand Challenge.
Напомним, что последний московский форум Intel для разработчиков собрал ещё большее количество посетителей. Это первый Форум Intel для разработчиков, проходивший в Москве весной, а также первый форум длительностью три дня.
Разработка многопоточных приложений
Зачем нужна многопоточность?
Для многих из нас двуядерные процессоры давно перестали быть чем-то недосягаемым. Каждый из производителей, как Intel, так и AMD, предлагают сейчас довольно широкий ассортимент процессоров для рынков серверов и настольных систем. Двуядерными CPU с недавнего времени комплектуются даже ноутбуки. Не мудрено, ведь будущее, как нас уверяют производители, именно за многоядерными технологиями. Сейчас два ядра, потом (уже в конце 2006 года) четыре… Но что мы получаем от этой многоядерности? Конечно, два ядра заметно ускоряют работу системы, ведь на каждом из ядер может обрабатываться отдельная задача.
Но как быть с задачами, особо требовательными к вычислительной способности процессора (кодирование видео, например)? Ведь прирост производительности будет не велик, если они будут обрабатываться одним ядром. А как сделать так, чтобы задача обрабатывалась всеми ядрами? Именно распараллеливание задачи на отдельные потоки может дать значительный прирост производительности. Сейчас, когда многоядерность набирает обороты, задача обеспечения многопоточности актуальна для всех разработчиков программного обеспечения. Важно не только создавать новые многопоточные приложения, но и оптимизировать под многоядерные процессоры старое программное обеспечение. В этом могут помочь специальные программные продукты, о которых и пойдёт речь в данной статье.
Использование преимуществ программного параллелизма на многоядерных платформах Intel
Именно так звучала тема доклада ведущего инженера Intel подразделения Intel Software and Solutions Group Вэй Ли (Wei Li). Надо отдать должное Intel: выпустив вспомогательное программное обеспечение для оптимизации приложений под свою новую микропроцессорную архитектуру Intel Core, она значительно облегчила жизнь разработчикам программных продуктов. Очень продуманное решение – помогать разработчикам выжать максимум из своих процессоров, не так ли?
В данном случае Intel предстаёт перед нами не только в качестве производителя “железа”, но и в качестве разработчика качественных программных продуктов. Инженеры подразделения Intel Software and Solutions Group не только разрабатывают платформенное ПО – отдельное внимание уделяется вспомогательному ПО для разработчиков.
Весь процесс организации многопоточности разбивается на несколько последовательных действий, для каждого из которых предусмотрены специальные вспомогательные программные средства.
Все эти средства Intel объединила в одном пакете программ.
Архитектурный анализ ПО: Intel VTune Analyzers
Целью данного этапа является поиск участков программы, требующих наибольшей вычислительной мощности. Здесь анализируется архитектура программного продукта. Для этого можно воспользоваться специальным инструментом-анализатором производительности Intel VTune, входящим в пакет Intel. С его помощью анализируется функциональная структура приложения, количество обращений к каждой функции, время их выполнения. На основе полученных данных с помощью утилиты Call Graph, входящей в данный инструмент, строится граф обращений к функциям.
 |
В верхней части скриншота видна таблица с вызываемыми функциями, относительным временем их выполнения и количеством обращений к ним. Ниже приведён граф вызовов функций и выделена одна из ветвей, которая требует наибольших вычислительных затрат.
После определения того, что следует распараллелить, можно перейти к следующему этапу.
Организация потоков: компиляторы Intel
Отыскав нужный участок кода программы, нужно определить вычислительные потоки. Для этого существует технология OpenMP, разработанная ещё в далёком 1997 году. Работа приложения, использующего OpenMP, начинается с основного потока, являющегося единственным. В приложении могут содержаться параллельные регионы, входя в которые, основной поток создает группы потоков. В конце параллельного региона группы потоков останавливаются, а выполнение основного потока продолжается. Важным моментом здесь является синхронизация отдельных потоков.
OpenMP прост в использовании. В него входят два базовых типа конструкций: директивы pragma и функции исполняющей среды OpenMP. Директивы pragma, указывают компилятору на реализацию параллельного выполнения блоков кода. Все эти директивы начинаются с #pragma omp. Функции OpenMP служат для изменения и получения параметров среды. Кроме того, OpenMP включает API-функции для поддержки некоторых типов синхронизации.
Для реализации параллельного выполнения блоков приложения нужно просто добавить в код директивы pragma и, если нужно, воспользоваться функциями библиотеки OpenMP.
 |
Компиляторы Intel C++ Compiler и Intel Visual Fortran Compiler снабжены поддержкой технологии OpenMP, следовательно, с их помощью можно организовать потоки для каждого ядра процессора. Кроме того, компиляторы наилучшим образом оптимизируют ваше приложение для архитектуры процессоров Intel
Отладка: Intel Thread Checker
Отдельный поток на каждое ядро – это полдела. Ещё на этапе организации потоков программист должен учесть так называемые “гонки данных” и блокировки. Допустим, один из потоков в процессе вычислений должен рассчитать значение некоторой переменной, а затем эта переменная должна быть использована во втором потоке, вычисляемом на другом ядре. А теперь представьте, что второе ядро уже запросило переменную, а первое не успело рассчитать верное значение. Такая ошибка может привести к некорректной работе приложения. Подобные случаи очень сложно отслеживать и исключать в процессе разработки приложения. Конечно, можно каким-либо образом свести к минимуму использование общих ресурсов, но избавиться от этого полностью попросту невозможно. Синхронизация вычислений на отдельных ядрах является важным моментом.
Но и на этот случай у Intel кое-что припасено – Intel Thread Checker, инструмент отладки.
При помощи этого инструмента очень легко проанализировать и исправить код написанного многопоточного приложения.
Thread Checker последовательно анализирует код, написанного приложения и помечает те места в программе, где возможно возникновение гонок или взаимоблокировок.
 |
Таким образом, программист выделил потоки на каждое ядро, исправил все возможные конфликтные ситуации. Что же теперь?
Оптимизация производительности: Intel Thread Profiler
Следующим шагом будет оптимизация производительности приложения. Выделяя потоки, а затем исправляя возможные конфликты, мы можем получить далеко не лучшее приложение, производительность которого, возможно, будет далека от ожидаемой. Причина этого может быть в том, что отдельные потоки из-за взаимной синхронизации вынуждены ожидать другие. Из-за этого простоя общая производительность может значительно упасть, да и аппаратная часть простаивает без работы. Возможно, некоторые распараллеленные и отлаженные участки кода вовсе не следовало разбивать на потоки, ведь время выполнения этого же кода в один поток соизмеримо. И тут Intel облегчает жизнь разработчику. В пакет входит инструмент Intel Thread Profiler. С его помощью программист может отследить те участки уже распараллеленного и отлаженного кода, которые пагубно сказываются на производительности всего приложения, которые приводят к наибольшим издержкам.
 |
Thread Profiler определяет в стеке вызова функций те синхронизирующие примитивы, которые далеко не лучшим образом сказываются на производительности. Обнаружив эти примитивы, разработчик может внести соответствующие изменения в код дабы увеличить производительность приложения.
Заключение по разработке многопоточных приложений
Как уже было отмечено, будущее процессоров за многоядерностью, а, следовательно, будущее программного обеспечения за многопоточностью. Поэтому разработчикам следует взять это на заметку и начать разрабатывать новые более производительные многопоточные приложения и оптимизировать под многопоточность старые. В этом ключ к дальнейшему успеху. Главное не упустить момент.
Intel предоставила отличный пакет программ в помощь разработчикам, который способен подтолкнуть особо консервативных к переходу на многопоточность. Использовать инструменты очень легко, и процесс разработки ПО с их помощью заметно упрощается. Такая политика Intel, на наш взгляд, положительно скажется не только на её репутации, но и на популярности её процессоров.
Wireless USB вживую
Доклад Александра Редькина, посвящённый стандарту Wireless USB, на котором был показан прототип флэш-накопителя, имеющего такой интерфейс, показался нам достаточно увлекательным. Помимо краткого обзора состояния развития стандарта, речь шла о разработке экосистемы WiMedia UWB, а также о сроках появления первых массовых устройств. Отмечалось, что сертифицированная продукция, совместимая со стандартом Wireless USB, использующая приемопередатчики WiMedia UWB, появится в продаже в течение следующих 12 месяцев.
Наверное, не лишним будет напомнить, что же с технической точки зрения представляет собой стандарт Wireless USB.
Он, так же, как проводной стандарт USB, имеет топологию “хост-устройство”, позволяет подключать до 127 устройств, поддерживает драйверы класса протокола, и, что немаловажно, имеет высокую степень интеграции хоста, то есть позволяет максимально упростить сами устройства, возложив как можно функций на хост. Что касается пропускной способности, то на расстоянии до трёх метров она составляет 480 Мбит/с, а на расстоянии до 10 метров – 110 Мбит/с, кроме того, возможно масштабирование, при котором скорость 1 Гбит/с вовсе не является пределом. Сегодня мы постоянно видим упоминания об энергопотреблении, естественно, что в разработке нового стандарта, особое значение уделялось этому параметру. В итоге, мощность составит 130-160 мВт для приёма/передачи. Ещё одна очень существенная проблема – безопасность. В этом плане также предусмотрены собственные решения, позволяющие надёжно защитить данные, практически не ограничивая при этом скорость работы. Что касается простоты использование нового оборудование, то планируется, что пользоваться им будет не сложнее, чем оборудованием обычного стандарта USB. Если учесть спектр устройств, где будет использовать новый стандарт, то такая простота кажется совершенно необходимым качеством, которым должно обладать оборудование. Однако, если вспомнить, то простота использования всегда заявлялась как преимущество того или иного стандарта, но вовсе не всегда мы это видели на практике.
Все желающие могли познакомиться со структурой пактов передаваемых данных, зависимостью времени передачи пакета от скорости передачи и размера пакета. Кроме того, были указаны реальные скорости передачи данных при различных скоростях канала. Так, для скорости канала 480 Мбит/с, реальная скорость передачи данных составляет 355,28 Мбит/с. Вообще, если говорить об эффективности WUSB, то для выделенной среды она составляет около 75%.
Доклад не только возобновил в памяти многие факты о Wireless USB, но и предоставил дополнительную информацию, в частности о том, что развитие всей экосистемы WiMedia UWB идёт по плану.
В завершение доклада был показан работающий прототип флэш-накопителя Wireless USB. Сразу отметим, что не следует пугаться размеров этого устройства показанного на снимке, это прототип, который в дальнейшем будет реализован в виде чипа.
Работающий экземпляр флэш-накопителя с интерфейсом Wireless USB.
Отметим, что эта штука на самом деле работает. Александр скопировал туда ролик из Ледникового периода 2, после чего показал его посетителям.
DARPA Grand Challenge
Многие наши читатели наслышаны о гонке роботов DARPA Grand Challenge, которая проводится в США. Напомним, что суть состоит в том, чтобы построить машину-робота, которая сможет проехать определённый маршрут длиной около 320 километров менее, чем за 10 часов. При этом маршрут указывается за 2 часа до старта с помощью GPS точек/коридора, вмешательство в работу системы в ходе гонок недопустимо. Путь пролегает по грунтовым дорогам, бездорожью и пустыне Мохаве. Примечательно, что команды участницы не получают федерального финансирования, однако, им есть за что бороться – приз этого года составлял 2 миллиона долларов.
Машина-победитель.
Победителем 2005 года стала команда Стэндфордского университета. Компания Intel принимала участи в создании их автомобиля и поделилась на форуме некоторыми секретами успеха “Стэнли”. Доклад Боба Креппса (Bob Crepps), технического специалиста по планированию, оказался очень интересным и познавательным и заинтересовал множество посетителей.
Боб Креппс рассказывает о гонке.
Для навигации команды используют систему глобального позиционирования – GPS, при помощи которой задают путь, и которая используется для определения местоположения. Однако, Земля – не идеально гладкий шар, да и пустыня не всегда пустынна и ровна. Поэтому, очевидно, что для прокладывания маршрута уже непосредственно во время поездки, нужно оценивать и состояние дороги: ямы, камни, которые нужно объехать, другие машины, к которым также не следует сильно приближаться, и многие другие параметры. Победитель использовал не только обычные видеокамеры для оценки дороги, но и лазерные сенсоры, которые позволяли работать с более высокой точностью и с более широкими рамками освещённости и радар, который работал на большем расстоянии. На основании всех полученных значений составлялся план движения, в соответствии с которым и передвигался “Стэнли”.
 |
 |
В результате работы всех систем строилась модель дальнейшего движения. Но здесь возникала проблема – поскольку максимальную точность дают лазерные датчики, а их дальность всего около 20 метров, что приемлемо для скорости около 45 км/ч, то пользоваться только ими было нельзя – не позволял лимит времени. Нужна была скорость до 70 км/ч.
Визуальный картограф.
Такая модель позволяла ехать с большей скоростью, имея более точное планирование дальних участков.
Для обработки данных со всех сенсоров и прокладки маршрута нужны огромные вычислительные ресурсы. Стэндфордский университет использовал для работы достаточно мощную платформу на основе blade-сервера из шести “лезвий” с процессорами Intel Pentium M.
Серверная комната в автомобиле.
Естественно, работа над проектом дала немало опыта. Команда получила ряд полезных уроков, которые позволяют учесть возможные ситуации. Например, это касается глубины луж. Конечно, в России все знают, что даже маленькая с виду лужа может оказаться открытым колодцем, но, оказывается, не везде так… Заехав во внешне небольшую лужу, можно завязнуть в грязи даже на таком “внедорожнике”, как Volkswagen Toureg.
Такая преграда не по силам “внедорожнику” Volkswagen Toureg.
Машина оказалась слишком гуманной – тормозила даже перед пролетающими птицами и бабочками. Согласитесь, это совсем ни к чему. Особое внимание требовалось уделить и скоростному режиму особенно на поворотах и ухабах. Согласитесь, не каждый день можно встретить перевернувшийся “Хаммер”.
Кто сказал, что “Хаммер” не опрокидывается?
К сожалению, в нашем материале мы не можем передать всей динамики, которая присутствовала во время доклада Боба Креппса. Чтобы погрузиться в мир этих гонок с головой, нужно, как минимум, видеть видеоматериалы, в которых запечатлены наиболее интересные моменты соревнований.
В дальнейшем, команда университета планирует принять участие в очередной этапе соревнований, в котором движение будет осуществляться не по пустыне, а по оживлённым трассам и городским улицам. 8 октября 2007 года командам участницам будет предложено направить свои транспортные средства из центра Сан-Франциско в центр Лос-Анджелеса. Что ж, пожелаем успехов команде Стэнли в подготовке к следующему этапу, о котором надеемся рассказать вам в будущем.
