40-х годов основными метриками производительности компьютеров неизменно оставались задержка (latency) и пропускная способность (throughput). Метрики эти со своими задачами справлялись, поскольку компьютеры использовались очень нехитрым образом. Всегда подразумевалось, что данные доступны, и только их объем и содержание могут повлиять на время выполнения. В такой ситуации запущенные задачи выполняются независимо друг от друга, а измерение скорости выполнения каждой из программ, включая операционную систему, определяет общую производительность компьютерной системы, для повышения которой надо лишь снижать задержки и повышать пропускную способность. Исходя из этого и были разработаны такие наборы тестов, как SPEC (Standard Performance Evaluation Corporation) [1] и EEMBC (Embedded Microprocessor Benchmark Consortium) [2].

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

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

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

Эволюция использования компьютерных систем

Как показано на рис. 1a, при традиционном использовании компьютера задача Т1 поступает на выполнение в систему, некоторое время исполняется и завершается. Через какое-то время другая задача Т2 поступает на выполнение и пользуется ресурсами компьютера. Никакой конкуренции между Т1 и Т2 нет, а есть только одна программа, которая управляет потоками и доступом к данным, один входной и один выходной поток.

Как показано на рис. 1б, современная модель использования компьютеров гораздо сложнее. Многие задачи выполняются одновременно, конкурируют за ресурсы и общаются друг с другом. В отличие от традиционных схем, преобладает асинхронный и потоковый ввод/вывод; здесь важны сигналы о внешних событиях, ввод команд от пользователя, с Web-камеры, мультимедиа и т.д., что меняет само представление о том, что такое производительность компьютера.

Уровень принятия решений, опирающийся на предварительное планирование, обеспечивает независимое выполнение задач и позволяет нескольким потокам ввода/вывода совместно использовать один физический канал связи. Этот уровень поддерживает работу в реальном времени и обеспечивает потребность пользователей в совместной работе. Сложные взаимодействия между задачами и компонентами оборудования не позволяют описать функционирование системы в целом, если исходить из работы только одной изолированной задачи или из последовательной работы нескольких задач. Из-за этого известный закон Амдала* не подходит для описания связанных систем с гетерогенными ресурсами, поскольку замедление в них при исполнении некоторых задач может повысить общую производительность [4].

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

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

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

Поворотная точка в проектировании

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

Недавний обзор International Technology Roadmap for Semiconductors, подготовленный Sematech, показывает, что процессоры с одним ядром не могут содержать более 25 млн. транзисторов. Многопроцессорные решения с «интеграцией менее эффективных процессоров общего назначения типа “система на кристалле” с более эффективными устройствами специального назначения должны стать следующим шагом компьютерной эволюции» [5]. Эксперты считают, что к 2009 году на одном кристалле можно будет расположить до 63 процессорных устройств — ядер и отдельных логических блоков. Переход к гетерогенным многопроцессорным системам на кристалле (single-chip heterogeneous multiprocessor, SCHM) произойдет в течение нескольких следующих лет и откроет новые ресурсы роста производительности, причем не только за счет тактовой частоты.

Первые SCHM-архитектуры для коммерческих устройств — это процессор Cell компаний Sony, Toshiba и IBM, а также Sunbridge Sandblaster [6, 7]. Процессор Cell ориентирован на настольные ПК и игровые консоли, а Sandblaster — на беспроводные терминалы. В обеих областях есть свои сложности— обработка мультимедийных данных и обработка сигналов — и то и другое предполагает возможность параллелизма на уровне потоков и данных. Чтобы использовать этот параллелизм, архитектуры Cell и Sandblaster сочетают в себе кластер процессоров, выполняющих одну инструкцию за такт над большим объемом данных, с одном скалярным процессором. Cell использует этот скалярный процессор для кооординаци работы архитектуры SIMD (Single Instruction Multiple Data, «один поток команд и множество потоков данных»), а Sandblaster использует его для выполнения задач пользовательского интерфейса. Ни в одной из архитектур нет процессоров, зарезервированных для каких-то специфических функций. Из-за своей нетрадиционной конструкции и моделей программирования процессоры Cell и Sandblaster называют «системами на кристалле» (System-on-Chip, SoC), но это не совсем точно. Правильнее их было бы называть «процессорами из процессоров».

Системы категории SoC ориентированы на выполнение конкретных приложений и строятся по методу быстрой компоновки интегральных схем, предназначенных для сложного, но четко определенного, фиксированного на момент разработки набора задач. Согласно идеологии SoC, кристалл разделен на несколько отдельных блоков, часть из которых могут быть программируемыми, но у каждого есть вполне определенная задача. В случае же Cell и Sandblaster весь кристалл рассматривается как программируемое устройство, которое должно уметь динамически перераспределять ресурсы. Еще одна их особенность — маркетинг этих процессоров — строится на подчеркивании их уникальных свойств, а не их вычислительной мощности.

Компьютерная обработка на основе сценариев

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

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

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

Непригодность существующих тестов и метрик

Тестовый набор представляет собой несколько приложений, позволяющих комплексно оценить работу процессора. SPEC CPU [1] — основной тест, используемый создателями компьютеров,— включает ряд инженерных и научных приложений, специально отобранных и модифицированных для того, чтобы свести к минимуму взаимодействие с операционной системой. Тест EEMBC содержит ядро и встроенные приложения [2]. Набор Stanford SPLASH измеряет время работы распараллеливаемых алгоритмов, позволяет аналогичным образом оценить традиционные многопроцессорные архитектуры [8]. Все приложения в этих тестовых наборах независимы и выполняются по отдельности. На рис. 1, a показан именно такой способ использования.

Производительность в SPEC измеряется, как ускорение s=rreference/rmeasured по отношению к эталонной системе. Поскольку цель любой компьютерной системы состоит в том, чтобы обеспечить отличную производительность при любой работе, ускорение каждого приложения трактуется одинаково, а общее ускорение определяется как геометрическое среднее. Геометрическое среднее приписывает большие веса приложениям с меньшей производительностью — если хотя бы один результат равен нулю, то и общий показатель равен нулю, что означает бесконечный вес для конкретного приложения. Таким образом, лучший результат покажут сбалансированные системы, которые больше подходят для приложений общего назначения, но этот метод не оценит адекватно функционирование систем, ориентированных на сценарии.

В комплекте SPEC имеется набор SPEC_rate для измерения пропускной способности многопроцессорных систем. Чтобы определить показатели SPEC_rate, компьютер одновременно выполняет n копий каждой из задач, а затем определяет все их время выполнения. Такой подход ориентирован на выполнение однородных задач, скажем, на приложения типа инженерного дизайна, Internet-хостинг, работу с базами данных и высокопроизводительные вычисления. Системы, ориентированные на сценарии, напротив, предусматривают существенно различные модели использования.

Некоторые новые тестовые наборы, такие как SYSmark и 3Dmark [9], предназначены для оценки коммерческих характеристик компьютерной системы. В SYSmark используются наиболее распространенные коммерческие приложения— Adobe Acrobat Reader, Macromedia Dreamweaver, McAfee VirusScan и Microsoft Office — в сочетании с входной информацией и данными, получаемыми от реальных событий. Различные приложения выполняются совместно в разных сценариях, например, в коммуникациях (электронная почта и поиск в Internet) и анализе данных (запросы в базы данных и операции над таблицами). Для каждого сценария выдается свой отчет. SYSmark оценивает время отклика, а не время счета, отражая тот факт, что многие приложения зависят от происходящих событий и могут находиться в «уснувшем» состоянии, пока пользователь с ними не взаимодействует [10].

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

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

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

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

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

Оценка функционирования

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

Предполагается, что система навигации должна включать в себя распознавание речи и оптимизацию маршрута, поиск в Internet, визуализацию и выполняться на SCHM-системах с RISC- и SIMD-ядрами. Программы распознавания речи и визуализации лучше работают на SIMD-ядрах, а оптимизация маршрута и поиск в сети лучше реализуются на RISC. На рис. 2 сравниваются несколько возможных реализаций навигационного сценария. Каждая группа столбиков определяет особенности реализации, а каждый столбик — высота которого соответствует сложности вычислений — представляет определенную задачу. Причинами различной сложности могут быть выбор алгоритма, количество обрабатываемых данных в системе или зависимость от входных параметров. Мы полагаем, что при бесконечной вычислительной мощности более высокая сложность приводит к росту полезности.

Из этого примера можно сделать три важных вывода:

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

В реализации 1 из рис. 2 нет программного обеспечения — оперативность идеальна, но пользоваться этой системой крайне неудобно. В реализации 8 нет гарантий быстродействия, но есть широкий спектр функций, который делает устройство очень полезным. В реализации 10 нагрузка слишком высока и работа замедляется, что становится определяющим и разрушает полезность. При использовании более мощного процессора оперативность будет улучшена и полезность такой более сложной реализации увеличится. Программное обеспечение всегда должно соответствовать оборудованию.

Сравнение реализаций 1–4, не содержащих распознавания речи, с реализациями 5–8 наглядно показывает влияние новой возможности — полезность достигает максимума в реализации 3, а затем начинает уменьшаться, поскольку вырос поток запросов на оптимизацию маршрута и поиск в Web, которые должны выполняться на менее эффективных SIMD-процессорах. Использование этих процессоров для распознавания речи, а не для улучшения выполнения уже существующих функций, повышает общую полезность устройства.

Реализации 5–8 также показывают важность достижения оптимального баланса. Когда распознаванию речи придается слишком большое значение, как в реализации 6, это может привести к нарушению времени отклика системы. В реализациях 7 и 8 баланс оптимизируется так, чтобы улучшить полезность без снижения оперативности, что приводит к несимметричному выделению компьютерных ресурсов.

Рис. 3 иллюстрирует динамическое поведение навигационной системы и то, как влияет на систему добавление дополнительных функций. На рисунке показаны разные ситуации в хронологическом порядке (слева направо). Навигационная система находится в ждущем режиме до тех пор, пока не получит словесный запрос, запускающий цепь вычислений, которые продолжаются, пока система не найдет нужный маршрут. С этого момента система периодически запрашивает GPS и Web-сайты, где получает информацию о трафике, а также предупреждает водителя о каждом повороте. Два столбика на рисунке иллюстрируют каждую ситуацию. Зеленый цвет показывает время выполнения, когда навигационная система работает одна, а желтый — время, когда система одновременно загружает и показывает видео.

График, приведенный на рис. 3, может выявить неожиданные последствия новой функциональности, неочевидные, если смотреть масштабнее, как на рис. 2. Скажем, загрузка карты — это не проблема для обычной навигационной системы, поэтому можно было бы и не задумываться о том, как добавление новой функции повлияет на производительность. А вот рис. 3 показывает, что одновременный просмотр потокового видео — это наихудший случай. Дальнейший анализ может показать, что в этом может быть виновата ограниченная полоса пропускания,а это может побудить разработчиков включить сжатие карт или использовать более сложный беспроводной протокол. Когда оценка производительности идет вразрез с традиционными предположениями, появляются совершенно новые возможности.

Новая эра оценок производительности

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

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

  • Включать в себя взаимодействие программного обеспечения и оборудования. Задачи могут ожидать друг друга, взаимодействовать, размножаться и покидать систему. При этом нагрузка на процессор может существенно меняться. На рис. 3 показан как раз такой тип динамического поведения, а также пример того, как несколько задач конкурируют за ресурсы.
  • Предоставлять четкую временную информацию для входов и выходов. Поскольку всего один «клик» мышкой может запустить целую сеть вычислений, важно четко знать их расположение относительно других событий. На рис. 3 показано, как включение потокового видео может повлиять на функционирование, но если система навигации находится в режиме ожидания, просмотр видео пройдет прекрасно. Такие выходы, как видео и музыка, предъявляют строгие требования к временным параметрам, от чего зависит и качество их выполнения.
  • Обрабатывать критические случаи. Сценарии должны изолировать изломы кривых показателей производительности. Поскольку быстродействие зависит от используемого оборудования, должен существовать механизм настройки требований различными способами. Реализация 9 на рис. 2 иллюстрирует этот тип действий.
  • Описывать целые наборы моделей использования. Хотя они и направлены на определенные типы использования, сценарно-ориентированные системы могут приносить пользу и в других режимах. Количественная оценка взаимодействий между основной и вторичными моделями использования просто необходима. Например, что лучше — иметь отличный карманный телевизор или пожертвовать некоторыми его функциями, но получить взамен возможность использовать это же устройство как телефон.

Итак, мы предлагаем кардинально изменить структуру тестирования для систем, ориентированных на сценарии. Соответственно, должны измениться и метрики.

Метрики для систем, ориентированных на сценарии, должны удовлетворять следующим критериям.

  • Различать элементы приложений по их полезности. У пользователей нет единых требований к функционированию всех задач или даже к частям одной задачи. На рис. 2, например, распознавание речи более важно, чем работа дисплея, поскольку водитель никогда не должен отвлекаться от дороги.
  • Учитывать нелинейность. Сложная задача, выполняемая в режиме реального времени, должна уложиться в поставленные сроки. После того как все сроки прошли, смысла в дальнейшем ускорении задачи может просто не быть. Нечто похожее происходит с людьми: скорость реакции у человека ограничена, и если события происходят быстрее, они просто не воспринимаются. Например, графическая задача бессмысленна, если образы будут меняться быстрее, чем время отклика монитора.
  • Описывать критические случаи. Понимание в системе всех взаимодействий, ориентированных на сценарии, требует знания того, в какой момент, в какой функции и в каком месте эти взаимодействия приводят к снижению общей производительности. Например, должен быть способ точно определить, почему в реализации 9 из рис. 2 резко снизилась производительность, или объяснить взаимодействия, которые происходят на рис. 3, когда загрузка карты происходит одновременно с просмотром потокового видео.
  • Обеспечивать визуальное представление. Картинки и графики — мощное средство для представления сложной информации и взаимодействий. Целесообразно использовать диаграммы со столбиками в сочетании со SPEC, чтобы демонстрировать улучшения в пропускной способности и уменьшение задержек. Разработчикам систем, ориентированных на сценарии, часто требуется выбрать один подход из множества альтернатив, когда оптимальный вариант совсем не очевиден. Надо добиться того, чтобы будущие тесты помогали принимать правильные решения.

Литература

  1. J.L. Henning, SPEC CPU2000: Measuring CPU Performance in the New Millennium. Computer, July, 2000, www.spec.org.
  2. M. Levy, Evaluating Digital Entertainment System Performance. Computer, July, 2005, www.eembc.org.
  3. J.M. Paul, D.E. Thomas, A. Bobrek, Scenario-Oriented Design for Single-Chip Heterogeneous Multiprocessors. IEEE Trans. VLSI, Aug. 2006.
  4. J.M. Paul, B.H. Meyer, Amdahl’s Law Revisited for Single Chip Systems. Int’l J. Parallel Programming, Apr., 2007.
  5. Sematech, International Technology Roadmap for Semiconductors (ITRS). 2005; www.itrs.net/Links/2005ITRS/Home2005.htm.
  6. H.P. Hofstee, Power-Efficient Processor Architecture and the Cell Processor. Proc. 11th Conf. High-Performance Computing Architectures, IEEE CS Press, 2005.
  7. M.J. Schulte et al., A Low-Power Multithreaded Processor for Software Defined Radio. J. VLSI Signal Processing Systems, June, 2006.
  8. S.C. Woo et al., The SPLASH-2 Programs: Characterization and Methodological Considerations. Proc. 22nd Ann. Int’l Symp. Computer Architecture, ACM Press, 1995.
  9. N. Renqvist, M. Kallinen, 3DMark06. White paper v1.0.2, Jan. 2006; www.futuremark.com/products/3dmark06.
  10. J.M. Sammons, C.H. Sauer, Measuring the Performance of Personal Computers. Proc. 37th IEEE Computer Society Int’l Computer Conf. (Compcon 92), IEEE CS Press, 1992.

Шон Пипер (spieper@wisc.edu )— аспирант факультета компьютерной инженерии университета Висконсинт-Мэдисон. Джоан Пол (jmpaul@vt.edu )— профессор факультета компьютерной инженерии технического университета Вирджинии. Майкл Сколт (schulte@ece.wisc.edu )— профессор факультета компьютерной инженерии университета Висконсинт—Мэдисон.

Sean Pieper, Joаnn Paul, Michael Schulte. A New Era of Performance Evaluation, IEEE Computer, September 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission.

* Закон Амдала, выражающий количественно закономерности роста производительности параллельных систем, указывает, что увеличение быстродействия параллельного приложения лимитируется возможностями последовательного приложения. См. например: Воеводин В.В.Параллельная обработка данных. Курс лекций.— Лаборатория параллельных информационных технологий НИВЦ МГУ, 2000.— Прим. перев.

Программное обеспечение многоядерных систем http://www.osp.ru/os/2006/02/1156508