В работах над средствами распараллеливания участвуют сотни сотрудников лабораторий Intel, расположенных в нескольких странах, в том числе в США, Индии и России. Руководители корпорации поделились видением перспектив параллельного ПО.

Intel, гигант полупроводникового рынка, является также одним из ведущих в мире разработчиков программного обеспечения, которое создают свыше 6 тыс. специалистов. В декабре в корпорации произошли изменения в высшем руководстве, в результате которой на ведущих позициях в иерархии появились новые имена, в том числе Джастин Раттнер, директор по микропроцессорным исследованиям, и Ричард Вирт, генеральный менеджер по программному обеспечению и решениям. Недавно Раттнер и Вирт встретились с корреспондентом еженедельника Computerworld и поделились своим видением перспектив развития ПО.

Джастин Ратнер: «В некоторых приложениях вспомога-тельные потоки дают ощутимый выигрыш»

Что нового в сфере разработки компиляторов?

Ричард Вирт (РВ): По-прежнему идут работы, направленные на совершенствование традиционных компиляторов, которые лучше адаптируют языки программирования для поддержки многопоточности и гиперпоточности. Хороший тому пример — OpenMP, проект, посвященный адаптации языков программирования к обработке многопоточности.

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

Но такого рода мониторы производительности уже существуют...

ДР: Современные мониторы производительности на самом деле предназначены для отладки, и они недоступны компилятору. Мы планируем разработать инструментарий, способный взаимодействовать с программой таким образом, чтобы компилятор мог работать во время ее выполнения. Это будет оперативный компилятор, задействованный в процессе.

Ричард Вирт: «Нам сейчас необходимы средства отладки и настройки произво-дительности»

Появятся ли новые виды параллельной обработки?

РВ: Мы добились реализации параллелизма выполнения команд на одном процессоре. Intel всячески развивает этот подход, поэтому мы начинаем реализацию многопоточности на одном процессоре. Затем предлагаем разместить несколько многопоточных процессоров на системной плате.

По мере увеличения числа транзисторов, вместо нескольких процессоров на системной плате мы будем устанавливать их на кристалле, на самой микросхеме. Такой подход называется двухядерным. Эти процессоры мы хотим объединить в крупные кластеры. Каждый узел, как это следует из закона Мура, станет мощнее, но наша задача — связывать вместе все больше и больше узлов, чтобы получить суперкомпьютер.

Каким образом вы намерены добиться большего параллелизма существующих приложений?

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

Насколько полезными окажутся эти вспомогательные потоки?

ДР: Мы стремимся использовать их по максимуму. В некоторых приложениях такие потоки дают выигрыш в два-четыре раза. В среднем мы рассчитываем, что производительность увеличится в 1,3-1,5 раза, а для определенных программ результаты окажутся просто поразительными.

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

РВ: Проблема заключалась в том, что создатели рассчитывали на компилятор. Предполагалось, что он все сделает за них, и для достижения этого были проведены серьезные исследования.

В результате мы пришли к выводу, что помощь программистов нам по-прежнему необходима. Вот почему был разработан OpenMP с «директивами», или подсказками, которые программисты добавляют в приложение для того, чтобы компилятор мог распараллелить код.

Но все это в большей степени касается научных вычислений. А что вы можете сказать по поводу коммерческих приложений?

РВ: Здесь происходит то же самое — разделение приложения на функции и поддержка взаимодействия между ними. Прекрасный тому пример — Web-службы. Протокол SOAP делает для бизнеса то, что MPI делает для сферы технических приложений, то есть позволяет объектам взаимодействовать друг с другом таким образом, чтобы можно было поддерживать масштабируемость на уровне кластера или распределенной сети.

К чему это все приведет и что для этого нужно?

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


Параллельная обработка — небольшой глоссарий

1. OpenMP. Спецификация для набора директив компилятора и библиотечных программ, которые могут использоваться для реализации параллелизма в рамках модели разделяемой памяти для программ на Фортране, а также Си и C++.

2. Message Passing Interface (MPI). Стандарт, который поддерживает разработку параллельных приложений. Он определяет синтаксис и семантику библиотечных программ для переносимых программ передачи сообщений, написанных на Фортране, а также Си и на C++.

3. HyperThreading («гиперпоточность»). Предложенный компанией Intel способ, благодаря которому операционная система или многопоточная пользовательская программа воспринимает один физический процессор как два логических процессора.

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

5. Вспомогательные потоки (helper threads). Небольшие строки команд, которые помогают лучше работать основному потоку приложения. Такие цепочки, сгенерированные компилятором, выполняются раньше основного потока и могут, например, заносить данные в кэш до того, как они потребуются.

Поделитесь материалом с коллегами и друзьями