Программная инженерия и смежные дисциплины

У тематической подборки, включающей шесть полноформатных статей, имеются приглашенные редакторы: Карл Чанг (Carl Chang), Дэвид Вейсс (David Weiss) и Майк Хинчи (Mike Hinchey), а их вводная заметка называется «Там, где программная инженерия пересекается с... » (Where Software Engineering Meets...). Программная инженерия — относительно молодая область, ко времени первого использования термина software engineering (SE) в 1968 году многие другие инженерные дисциплины существовали уже многие годы. С тех пор программная инженерия проникла практически во все аспекты современной жизни людей и становится все более практичной и зрелой областью. По причине молодости программной инженерии ее теоретические основы разработаны не так глубоко, как в более зрелых дисциплинах, поэтому в исследованиях в этой области широко используются знания, накопленные в смежных дисциплинах и прикладных областях. Какие же другие области исследований оказывают основное воздействие на развитие принципов и практических методик применения в данной области?

C 1968 года на программную инженерию больше всего влияли инженерные дисциплины — многие авторитетные специалисты, являющиеся сторонниками превращения ее в истинно инженерную дисциплину, полагают, что при разработке сложных и надежных программных систем необходимо правильно понимать и точно применять надлежащие инженерные принципы и практические методики. Многие единодушны в том, что данной дисциплине следует прагматически перенять многие инженерные термины и методы.

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

Первую регулярную статью тематической подборки под названием «Теория и практика программной инженерии» (Can Practitioners Neglect Theory and Theoreticians Neglect Practice) представил Манфред Брой (Manfred Broy). Теория помогает инженерам традиционных специализаций создавать и изучать методы, оценивать результаты и оптимизировать процессы. В статье обсуждает вопрос: играет ли теория аналогичную роль в программной инженерии?

Автором статьи «Open Source: уроки для программной инженерии» (Open Source Software: Lessons from and for Software Engineering) является Брайан Фицджеральд (Brian Fitzgerald). В проектах разработки программного обеспечения с открытым кодом применяются многие принципы программной инженерии, и, наоборот, традиционной программной инженерии есть чему поучиться у разработчиков ПО с открытым кодом.

Следующая статья называется «Программная инженерия и эволюционные вычисления» (Software Engineering Meets Evolutionary Computation) и написана Марком Харманом (Mark Harman). Программное обеспечение эволюционирует — этот факт был осознан еще в самом начале истории программной инженерии, и, хотя термин «эволюция программного обеспечения» используется по отношению к процессу, в ходе которого программные системы постоянно приспосабливаются к изменениям требований и среды функционирования, его нельзя считать чисто техническим. Эволюция ПО имеет явную связь с классической дарвиновской эволюцией. Независимо от этого в компьютерных науках появился термин «эволюционные вычисления» (evolutionary computation) со строгим техническим смыслом: исследование алгоритмов, в которые закладываются критерии поиска в пространстве возможных решений с целью нахождения наилучших способов решения заданной проблемы. В сообществе эволюционных вычислений проводятся конференции и издаются журналы, посвященные разработке и применению эволюционных методов в автоматизированных процессах метаэвристической оптимизации.

В компьютерных науках эволюционные вычисления используются для оптимизации разработки артефактов и процессов в самых разнообразных инженерных областях. Однако, как это ни странно, до конца прошлого века сравнительно мало исследований посвящалось применению эволюционных вычислений (и других методов поисковой оптимизации) в области инженерии программного обеспечения. Это привело к образованию новой области исследований, называемой поисковой инженерией программного обеспечения (search-based software engineering, SBSE) и посвященной применению методов поисковой оптимизации для решения проблем программной инженерии.

В последнее десятилетие исследователи применяли SBSE в ряде направлений программной инженерии, включая анализ требований, прогнозное моделирование, проектирование, тестирование и рефакторинг, были разработаны многочисленные методы поисковой оптимизации. Описание некоторых из них содержится в обзоре автора статьи.

Нет причин, по которым SBSE должна была бы опираться только на эволюционные вычисления, можно использовать и другие алгоритмы оптимизации, и они действительно используются. Например, в июне 2011 года в 587 из 830 публикаций по тематике SBSE, собранных в репозитории SBSE, использовался по крайней мере один метод оптимизации. В 9% статей применялись какие-либо эволюционные алгоритмы, в 45,5% – генетические алгоритмы, в 13,5% – генетическое программирование, в 0,6% – эволюционные стратегии, в 1,8% – метод роя частиц, в 1,4% – алгоритмы оценки распределений и в 0,8% – рассеянный поиск. Однако эволюционные вычисления использовались в 71% всех статей по тематике SBSE (рис. 1), и это единственный метод оптимизации, применимый в любом направлении инженерии ПО.

Рис. 1. Рост числа публикаций по тематике SBSE и сопутствующий рост числа публикаций, посвященных применению эволюционных вычислений в программной инженерии

Робин Лац (Robyn Lutz) представил статью «Применение программной инженерии в области исследований космического пространства» (Software Engineering for Space Exploration). Новые достижения в области построения автоматических космических аппаратов преобразуют сферу исследования космического пространства — в космических аппаратах используется все больше ПО для поддержки более интеллектуального удаленного управления, более быстрого и точного обнаружения и устранения неисправностей, более совершенного сбора и анализа научных данных для лучшего понимания нашей вселенной. В 2011 году NASA подготовило космические экспедиции для составления карты гравитационного поля Луны, исследования того, как сформировался Юпитер и другие гигантские планеты, а также запустило программу Mars Science Laboratory, в рамках которой на Марс будет доставлен автоматический марсоход Curiosity, предназначенный для исследования марсианской среды (рис. 2).

Рис. 2. Эволюция марсоходов. Слева направо: один из двух марсоходов 2004 года – Spirit и Opportunity; марсоход Pathfinder 1997 года и марсоход Curiosity 2011 года (фотография NASA/JPL-Caltech)

Несмотря на все усилия инженеров, эти исследования являются опасными для автоматических космических аппаратов как вблизи Земли, так и в далеком Космосе. Некоторые факторы внешней среды наносят вред бортовым программным системам, хотя отдельные неожиданности вполне приятны (например, космическому аппарату Voyager 2 удалось засвидетельствовать взрыв сверхновой звезды), однако большинство непредвиденных событий или обстоятельств может привести к повреждению или разрушению систем.

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

Программная инженерия играет жизненно важную роль для обеспечения инструментальных средств, методов и систематических подходов к разработке и поддержке многих видов ПО, требуемого в космических исследованиях. Применение разработки программ на основе моделей, формальной верификации и разработки линеек продуктов обеспечивает соответствие возможностей ПО потребностям космических исследований, надежное и корректное функционирование космических аппаратов. Автоматические космические аппараты — непилотируемые средства, которые управляются командами, посылаемыми с Земли или «зашитыми» в бортовые программы, — являются авангардом космических исследований, поскольку они могут отправляться в места, недоступные для пилотируемых космических полетов. Поскольку многие автоматические космические аппараты выполняют далекие путешествия и должны нормально функционировать в течение долгого времени, они должны быть очень надежными.

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

Статья «Программная инженерия, сервисные архитектуры и облака» (Software Engineering Meets Services and Cloud Computing) написана Стивеном Яу (Stephen Yau) и Хо Эном (Ho An). Сервисная архитектура (Service-Oriented Architecture, SOA) и облака привлекают сегодня внимание индустрии и науки, поскольку позволяют быстро разрабатывать масштабные распределенные приложения в таких областях, как совместные исследования и разработки, электронный бизнес, здравоохранение, приложения с использованием grid, корпоративные компьютерные инфраструктуры, военные приложения и национальная безопасность. Эти парадигмы облегчают и удешевляют создание как простого коммерческого программного обеспечения, так и сложных критически важных приложений.

В обеих парадигмах используются понятия аутсорсинга ресурсов и передачи ИТ в ведение поставщиков услуг, но упор в них делается на разные аспекты программной инженерии. В SOA на переднем плане находится архитектурный дизайн, позволяющий разрабатывать приложения путем обнаружения и композиции сервисов. Облака ориентируются на эффективную доставку сервисов за счет гибкой и масштабируемой виртуализации ресурсов и балансировки нагрузки. Сервисная программная инженерия (Service-Oriented Software Engineering, SOSE) объединяет лучшие черты этих парадигм. Изначально SOSE основывалась на SOA, но впоследствии стала затрагивать и облака: SOA обеспечивает архитектурный стиль, стандартные протоколы и интерфейсы, требуемые для разработки приложений, а облачная инфраструктура используется для доставки пользователям требуемых сервисов. Соединение SOA и облаков в инфраструктуре программной инженерии может помочь разработчикам и поставщикам сервисов справиться с проблемами каждой из этих парадигм.

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

Последняя статья тематической подборки написана Дэвидом Лорджем Парнасом (David Lorge Parnas) и называется «Инженерия программного обеспечения – без вести пропавшая: личная точка зрения» (Software Engineering – Missing in Action: A Personal Perspective). Уже в 60-х годах программное обеспечение начало становиться проблемой — было принято считать, что аппаратура готова и работает, а ПО является неполным и ненадежным. Разработка программ обычно не укладывалась в выделенный бюджет, нарушались плановые графики, а конечный результат не отвечал ранее установленным требованиям. Многие разработчики начали понимать, что они делают не совсем то, чему их учили, — они готовились стать учеными или математиками и вносить свой вклад в общечеловеческое знание, а в действительности им приходилось производить продукты, которыми должны были пользоваться другие люди.

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

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

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

Вне тематической подборки в октябрьском номере опубликована статья «Управление питанием дисплея с выявлением намерений пользователей» (Display Power Management That Detects User Intent), авторами которой являются Джей Мин Ким (Jae Min Kim), Миньен Ким (Minyong Kim), Джунго Конг (Joonho Kong), Хиюнг Беом Джанг (Hyung Beom Jang), Сун Ву Чунг (Sung Woo Chung). Расширение областей применения компьютеров приводит к тому, что все чаще люди используют ноутбуки, а не настольные ПК. Соответственно обостряется проблема продления времени работы аккумуляторных батарей за счет продуманного управления питанием дисплеев (Display Power Management, DPM). Хотя энергопотребление дисплея различно у разных ноутбуков, оно составляет около 30% общего энергопотребления устройства, что выглядит логичным, когда пользователям требуются высококачественные изображения, видео и т.д., но расточительным, когда пользователь не смотрит на экран. Вопреки распространенному мнению, скринсейверы не слишком способствуют снижению уровня энергопотребления, а накладные расходы на их запуск могут даже повысить общее энергопотребление системы.

Экономии энергии ничто не способствует больше, чем простое выключение дисплея, поэтому очевидным направлением совершенствования DPM является создание механизма, который бы определял намерения пользователя и выключал дисплей не только когда пользователь отсутствует, но и тогда, когда дисплей не используется. Решению этой проблемы посвящалось несколько исследований. В типичных ОС обеспечиваются DPM с таймером, выключающие дисплей при длительном отсутствии ввода, а в некоторых работах предлагались DPM с более тонкими механизмами выявления намерений пользователей, основанными, например, на использовании ультразвука для обнаружения присутствия пользователя.

Авторы статьи разработали схему, улучшающую выявление намерений пользователей посредством обнаружения состояний пользовательского присутствия за дисплеем на основе изображений, получаемых с веб-камер. Это позволяет определить, например, внимателен пользователь или дремлет, а чтобы избежать ложного выявления намерений, было введено промежуточное состояние — «слабое внимание», приводящее к тому, что алгоритм анализа изображения лица пользователя начинает чаще анализировать новое изображение (рис. 3).

Рис. 3. Диаграмма смены состояний схемы DPM. Использование клавиатуры или мыши переводит механизм в активное состояние. Веб-камера позволяет установить, смотрит пользователь на дисплей, не смотрит или вовсе отсутствует. Состояние слабого внимания не соответствует какому-либо физическому состоянию пользователя, а заставляет алгоритм анализа изображения лица пользователя повторно проверить, смотрит ли пользователь на экран

Авторы экспериментально установили, что их схема поддерживает ноутбук в режиме пониженного потребления энергии в течение примерно 50% времени его использования, а другие DPM достигают этого только в течение 30-40% времени. При этом эффекты, вызывающие раздражение пользователей, возникают не чаще одного раза в час.

Совместная разработка: путь к экзафлопсам

Тема ноябрьского номера журнала Computer — совместная разработка аппаратуры и программного обеспечения экзафлопсных систем.

В тематической подборке три полноценные статьи, которым предшествует вводная заметка приглашенных редакторов «Совместная разработка систем и приложений: прокладывание пути к вычислениям экзафлопсного диапазона» (Codesign for Systems and Applications: Charting the Path to Exascale Computing). Редакторы тематической подборки: Владимир Гетов (Vladimir Getov), Адольфи Хойзи (Adolfy Hoisie) и Харви Вассерман (Harvey Wasserman).

Сегодня наука о вычислениях (computational science) стала жизненно важным инструментом, оказывающим решающее воздействие на развитие практически всех научных и инженерных дисциплин, имеющих значительное общественное влияние. Постоянная потребность в возрастающей вычислительной мощности стимулировала HPC-сообщество на поиск путей движения к системам экзафлопсного уровня производительности. Однако для этого необходимо решить ряд сложнейших проблем. Недавнее исследование DARPA показало, что даже при наличии технических возможностей экзафлопсные системы, разработанные по применяемым сегодня технологиям, непрактичны, поскольку потребляли бы энергию в сотни мегаватт в час, что недопустимо. Рост частоты процессоров больше не подчиняется закону Мура, и целью сообщества HPC становится достижение сверхвысокой производительности при наличии строгих ограничений на надежность и энергопотребление.

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

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

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

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

Особенностью встраиваемых систем является наличие всего лишь нескольких приложений, недоступных конечным пользователям. Для этих приложений имеются требования фиксированного времени выполнения — дополнительная динамически обеспечиваемая энергия для них не нужна. В отличие от этого, в вычислительных системах общего назначения выполняется широкий класс приложений, программируемых конечными пользователями, — чем быстрее эти приложения выполняются, тем лучше, а для этого в критерии разработки требуется включать стоимость и пиковую скорость. Суть проблемы совместной разработки экзафлопсных систем состоит в том, что при использовании критериев разработки встраиваемых систем (стоимость и энергопотребление) требуется создавать системы, полезные и эффективные при выполнении разнообразных научных приложений. «Одноразовые» экзафлопсные системы обречены на неудачу.

В области HPC совместная разработка использовалась, например, при создании суперкомпьютера IBM BlueGene/L и в проекте PERCS, выполнявшемся в рамках программы DARPA High-Productivity Computing Systems. Два прекрасных дополнительных примера совместной разработки суперкомпьютеров для поддержки приложений молекулярной динамики представляют проекты MDGrape японского исследовательского института RIKEN и Anton лаборатории D.E. Shaw Research.

В проекте IBM RoadRunner были намечены пути к использованию гибридных архитектур, когда в систему в дополнение к процессорам общего назначения включаются специализированные элементы, позволяющие ускорить выполнение конкретной рабочей нагрузки. Однако неоднородность результирующей архитектуры, для использования которой требуется «смесь» из нескольких моделей программирования, вызывает значительные проблемы. Кроме того, в приведенных примерах совместной разработки критерием успеха была производительность, а энергопотребление и надежность во внимание не принимались.

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

Первую регулярную статью тематической подборки написали Джон Шелф (John Shalf), Дэн Квинлан (Dan Quinlan) и Куртис Янссен (Curtis Janssen), и называется она «Переосмысление совместной разработки аппаратуры и программного обеспечения систем экзафлопсного диапазона» (Rethinking Hardware-Software Codesign for Exascale Systems). В течение многих лет пользователи систем HPC наблюдали повышение пиковой производительности без соразмерного повышения общей производительности приложений. Кроме того, по мере достижения этими системами экзафлопсного уровня разработчики сталкиваются с многочисленными ограничениями на энергопотребление. Расходы на энергоснабжение могут превысить стоимость приобретения систем HPC, что, в конце концов, ограничит уровень практичности их применения.

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

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

В проекте Codesign for Exascale (CoDEx) формируется комплексная среда совместной разработки аппаратуры и программного обеспечения, назначение которой — обеспечить разработчиков приложений и алгоритмов возможностью влиять на направление развития будущих архитектур систем HPC в соответствии с требованиями программы Минобороны. В CoDEx объединяются три элемента: гибкая потактовая симуляция архитектур узлов с использованием результатов проекта Green Flash Национальной лаборатории в Беркли; средства извлечения и экзамасштабной экстраполяции трасс обращений к памяти и сетевых взаимодействий с использованием инфраструктуры компилятора ROSE Ливерморской национальной лаборатории им. Лоуренса; масштабируемая симуляция массивных межсетевых соединений с использованием набора инструментальных средств Национальной лаборатории Сандия.

Статья «Совместная разработка кластеров, основанных на InfiniBand» (Codesign for InfiniBand Clusters) представлена Саянтаном Суром (Sayantan Sur), Кришной Кандаллой (Krishna Kandalla), Харри Субрамони (Hari Subramoni), Дхабалесваром Пандой (Dhabaleswar Panda) и Карен Томко (Karen Tomko). В научных вычислениях приходится иметь дело с громадными объемами данных, и из-за своей насыщенности вычислениями и данными такие приложения часто выполняются одновременно на нескольких компьютерах. Сегодня системы преодолели петафлопсный барьер, и эксперты ожидают достижения экзафлопсного уровня в течение десятилетия. Чтобы сохранить возможность масштабирования приложений на все более мощных системах, необходимо исследовать новые архитектуры с системной точки зрения и новые парадигмы программирования – с позиций разработчиков приложений. В подходе к совместной разработке, описываемом в статье, применяются развитые возможности аппаратуры межсетевых соединений InfiniBand, разработка опирается на использование современной коммуникационной библиотеки поддержки интерфейса обмена сообщениями MPI, а затем приложения модифицируются так, чтобы в них максимально применялись эти новые возможности.

Авторами последней статьи тематической подборки являются Даррен Кербисон (Darren Kerbyson), Абхинав Вишну (Abhinav Vishnu), Кевин Бэйкер (Kevin J. Barker) и Адольфи Хойси (Adolfy Hoisie), а статья называется «Проблемы совместной разработки систем экзафлопсного диапазона: производительность, энергопотребление и надежность» (Codesign Challenges for Exascale Systems: Performance, Power, and Reliability). В настоящее время привычны системы с сотнями тысяч процессоров, иерархии памяти обычно включают три уровня кэша, а в ближайшее время будут доминировать топологии межсетевых соединений с петлями (mesh), толстыми деревьями (fat tree) и полной иерархической связанностью. Оптимизация по отношению к некоторой архитектуре – это всего лишь одна из многих фаз жизненного цикла приложения. Однако этот распространенный процесс можно назвать односторонним, поскольку он применяется по отношению к уже разработанным и реализованным архитектурам. У будущих систем и приложений появятся дополнительные требования производительности, энергопотребления и отказоустойчивости, порождающие многомерную проблему оптимизации. Процесс совместной разработки может помочь оптимизировать две или большее число подобных характеристик с целью получения улучшенного решения. В конечном счете этот процесс ведет к созданию настраиваемых систем экзафлопсного уровня.

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

Как показано на рис. 4, в процессе совместной разработки крупномасштабных систем пять факторов способствуют повышению сложности:

• разные алгоритмы, используемые в вычислениях, могут обладать разными вычислительными характеристиками, а реализации сеточных алгоритмов с неизменным шагом сетки требуют больше памяти и обменов сообщениями, чем реализации алгоритмов с измельчением сетки;
• приложение является реализацией некоторого метода и компонентов общей рабочей нагрузки, а при совместном использовании нескольких приложений можно одновременно обследовать несколько аспектов физической системы;
• в основе приложения лежит модель программирования, определяющая способ представления вычислений, и здесь распространены два подхода к реализации параллелизма: подход, основанный на процессах, когда межпроцессорные взаимодействия представляются явным образом с использованием, например, MPI, и подход, в центре которого находятся данные, и доступ к любым данным системы может быть произведен с любого узла (например, Global Arrays, Unified Parallel C и Co-Array Fortran);
• система поддержки времени выполнения обеспечивает удовлетворение динамических требований приложений и отображение этих требований на ресурсы системы, что включает, в частности, управление процессами и данными;
• архитектура включает микроархитектуру ядер процессоров, компоновку ядер внутри кристалла, иерархию памяти, системные межсетевые соединения и подсистемы хранения данных.

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

Вне тематической подборки опубликованы три крупные статьи. Статью «iPlant Collaborative: киберинфраструктура снабжения мира продовольствием» (The iPlant Collaborative: Cyberinfrastructure to Feed the World) представил Дан Станционе (Dan Stanzione). Общепризнана важность вычислений для получения новых научных результатов, поэтому и продолжается финансирование исследования в области крупномасштабных вычислений. Одним из наиболее крупных достижений в этой сфере является среда Extreme Science and Engineering Discovery Environment (XSEDE), ранее называвшаяся TeraGrid. Эта среда была создана в ходе пятилетнего проекта, поддерживавшегося Национальным научным фондом США, и предоставляет тысячам исследователей со всего мира доступ к 16 суперкомпьютерам и развитым электронным ресурсам. Проект iPlant Collaborative во многих отношениях представляет пример нового подхода к крупномасштабным инвестициям в научные вычисления. iPlant является одним из первых киберинфраструктурных проектов, финансируемым Фондом и направленным на поддержку наук, опирающихся на истинные, а не модельные данные, в частности, ботаники. Кроме того, этот проект должен предоставить исследователям не просто доступ к суперкомпьютерам, базе данных и инструментальным средствам, а снабдить их полной архитектурой, предназначенной для поддержки исследований. Наконец, проект iPlant направлен не на поддержку решения каких-либо конкретных научных задач, а опирается на уникальный синтетический подход, позволяющий научному сообществу формулировать фундаментальные проблемы.

Почему таких вычислительных инвестиций заслужила ботаника, если учесть, что общее финансирование науки продолжает сокращаться? Во-первых, растения критически важны для обеспечения надежного будущего: ожидаемому к 2050 году 9,3-миллиардному населению Земли потребуется в два раза больше продовольствия. Во-вторых, ботаника находится на той стадии, когда от возможности вычислений зависит получение новых научных результатов. Например, небольшая лаборатория может каждые несколько дней производить терабайт данных, и эта скорость растет быстрее, чем требовал бы закон Мура. В-третьих, сегодняшняя ботаника – это наука, опирающаяся на истинные данные.

Авторами статьи «Защита от уязвимостей переполнения буфера» (Defending against Buffer-Overflow Vulnerabilities) являются Бинду Мадхави Падманабхуни (Bindu Madhavi Padmanabhuni) и Хи Бен Куан Тан (Hee Beng Kuan Tan). В 2003 году уязвимости переполнения буфера называли «уязвимостями десятилетия», а затем сообщество Open Web Application Security Project (OWASP) сочло этот класс уязвимостей пятой по уровню серьезности слабостью веб-приложений. За первые пять месяцев 2010 года в Национальной базе данных уязвимостей (National Vulnerability Database) было зафиксировано 176 уязвимостей этой категории, из которых 136 были признаны серьезными. Переполнение буфера и сегодня остается одной из основных дыр в системах безопасности, занимая третье место в списке 25 наиболее опасных программных ошибок ( Top 25 Most Dangerous Software Errors ).

Переполнение буфера происходит, когда приложение производит запись за пределами границ заранее выделенного буфера фиксированного размера. Уязвимости такого типа обычно свойственны приложениям, написанным на языках Си и C++, поскольку в них допускается запись в любую область памяти без проверки выхода адреса за установленные границы. Обзор компьютерных вторжений с использованием уязвимостей переполнения буфера и анализ имеющихся решений для защиты от таких вторжений демонстрируют недостатки существующих систем безопасности, а также обеспечивают основу для внесения в них изменений, защищающих от таких вторжений.

Последнюю крупную статью номера написали Джузеппе Нути (Giuseppe Nuti), Махнуш Мирфаеми (Mahnoosh Mirghaemi), Филип Треливен (Philip Treleaven) и Чайакорн Йингсаери (Chaiyakorn Yingsaeree) и она называется «Алгоритмический трейдинг» (Algorithmic Trading). Достижения телекоммуникационных и компьютерных технологий последнего десятилетия привели к созданию сложных динамических мировых рынков, что, в свою очередь, стимулирует развитие торговли с использованием компьютерных программ и приводит к появлению систем алгоритмического трейдинга, автоматизирующих одну или несколько стадий процесса трейдинга. Эти системы направлены на поиск аномалий в рыночных ценах, использование статистических паттернов одного или нескольких финансовых рынков, оптимальное исполнение заказов, маскировку намерений трейдера, обнаружение и использование стратегий конкурентов.

Институциональные трейдеры и менеджеры пенсионных фондов, паевых фондов и фондов венчурного инвестирования все чаще внедряют алгоритмические трейдинговые системы, которые сегодня управляют 50-60% всех торговых операций над акциями в США и ЕС. Высокочастотный алгоритмический трейдинг в 2009 году отвечал за продажу и покупку 60% акций в США и является основной движущей силой развития компьютинга и аналитики, в особенности машинного обучения и вычислений с использованием Grid и графических процессоров. Однако алгоритмический трейдинг представляет серьезную проблему для контрольно-надзорных органов, и это иллюстрируют события 6 мая 2010 года, когда индекс Доу-Джонса упал на 600 пунктов в течение 5 минут, что привело к потере 600 млрд долл. в рыночной стоимости американских облигаций. Это показало недостаточность знаний о высокочастотном алгоритмическом трейдинге и его потенциальную уязвимость. Чтобы защититься от повторения таких событий, требуется глубокое понимание процесса трейдинга.

Всего доброго, Сергей Кузнецов (kuzloc@ispras.ru).