Поскольку размер статьи достаточно большой, я буду публиковать ее перевод частями, в соответствии с тем, как опубликован оригинал в ACM Queue
Программное обеспечение и параллельная революция
Херб Саттер (Herb Sutter) и Джэймс Лэрус (James Larus), Microsoft.
Использование всей мощи многоядерных процессоров требует новых инструментов и нового мышления от программной индустрии.
Часть 1. Последствия
Параллелизм уже давно декларируется как «последняя крутая фича» и «путь в светлое будущее», однако за последние 30 лет, основные направления в разработке программного обеспечения умудрялись его игнорировать. Однако наше параллельное будущее наконец то наступает: новые компьютеры будут действительно параллельными и это потребует значительных изменений в способах разработки ПО.
Во вводной статье этого номера (“The Future of Microprocessors” by Kunle Olukotun and Lance Hammond) рассматриваются аппаратные императивы которые определяют переход от монолитных к многоядерным процессорам, также известным как CMPs (chip multiprocessors). (Для анализа см. “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.”)(1)
В этой статье мы сосредоточимся на влиянии, оказываемом параллелизмом на программное обеспечение, и на тех последствиях, которые он влечет для программ и программистов.
Изменения в аппаратном обеспечении, которые описывают в своей статье Kunle Olukotun and Lance Hammond являются фундаментальными, и влекут изменения в компьютинге в целом. За последние три десятилетия прогресс в области полупроводников и процессорных архитектур создавал устойчивый рост скорости, с которой компьютеры исполняют существующие последовательные программы. Архитектурные изменения в многоядерных процессорах способны принести реальную отдачу только для параллельных приложений, и поэтому от них мало проку при использовании большинства из существующего ПО. В обозримом будущем десктопные приложения не будут работать более быстро, чем сегодня. А фактически, они могут оказаться и более медленными на новейших чипах, поскольку отдельные процессорные ядра становятся проще и работают на более низких частотах в целях сокращения общего энергопотребления многоядерных процессоров.
Это подводит нас к поворотной точке в области разработки ПО. Компьютеры продолжат становиться все более производительными, однако программы не смогут более повышать свою производительность, просто оседлав волну роста аппаратных возможностей, если только они не станут параллельными.
Помимо многоядерных процессоров есть и другие причины для использования параллельных вычислений, такие как асинхронное выполнение вычислений для улучшения отклика. Например, современные приложения могут выносить часть работы за пределы GUI потока, чтобы дать ему возможность обрисовывать экран, пока производятся вычисления в фоновом режиме.
Но параллелизм сложен. Современные языки и инструменты неадекватны задаче превращения приложений в параллельные программы, и как следствие, сложно отыскать параллелизм в современных массовых приложениях. Но хуже всего то, что параллелизм требует соответственно мыслящих программистов, которых также очень трудно найти.
Тем не менее, будущее за многоядерными машинами и мы должны понять, как их программировать. Оставшаяся часть статьи покажет, почему это сложно, и какие существуют пути решения.
Последствия: новая эра в области программного обеспечения
Сегодня параллельные языки и инструменты находятся на том же уровне, что и обычные языки в начале эры структурного программирования. Семафоры и сопрограммы - это ассемблер параллелизма, блокировки и потоки – это несколько более высокий, структурированный уровень параллельных вычислений. То, что нам нужно – это абстракции высокого уровня, помогающие создавать параллельные программы, подобно тому, как ООП помогает создавать сложные, составные компонентные приложения.
По ряду причин, параллельная революция может оказать на разработку ПО большее влияние, чем ООП революция. Во-первых, параллелизм будет неотъемлемой частью высокой производительности. Языки, не поддерживающие ООП, такие как C, продолжали использоваться для многих программ. Если же параллелизм станет ведущей чертой высокопроизводительного железа, ценность коммерческих и системных языков программирования будет напрямую зависеть от степени поддержки в них параллельного программирования. Существующие языки, такие как C, получат параллельные возможности в виде простых моделей, таких как PThreads. Языки которые не поддерживают параллельное программирование постепенно отомрут и будут использоваться только для поддержки старого оборудования.
Вторая причина, по которой параллелизм более серьезно повлияет на разработку, чем ООП, состоит в том, что параллельное программирование явно сложнее обычного. Например, контекстный анализ последовательных программ является фундаментальной техникой, в соответствии с которой, мы принимаем во внимание контекст вызова при анализе программы. Параллельное программирование также требует анализа синхронизации, однако одновременное применение обеих техник анализа представляется практически неразрешимой задачей (2).
И, наконец, люди быстро устают от параллелизма, они находят его слишком сложным для того чтобы использовать его на равных с последовательным программированием. Ведь даже очень внимательный человек легко может упустить возможные взаимные влияния при одновременном исполнении нескольких операций.
Различия между клиентскими и серверными приложениями.
Параллелизм, это проблема, которая стоит перед клиентскими приложениями. Для
большинства серверных приложений, параллелизм, в общем-то «решенная проблема», потому что обычно мы создаем решения которые довольно хорошо работают в параллельном режиме, однако создание их и обеспечение масштабируемости по-прежнему стоит громадных усилий. Эти приложения обычно изобилуют параллелизмом, потому что они одновременно обрабатывают множество независимых потоков запросов. Например, web сервер или web сайт независимо исполняют тысячи копий одного и того же кода, оперирующего преимущественно независимыми данными.
Кроме того, эти потоки исполняющегося кода хорошо изолированы и разделяют состояние посредством абстрактных хранилищ данных, таких как базы данных, которые поддерживают доступ к структурированным данным с высокой степенью параллелизма. Со стороны нам кажется, что этот код работает с разделяемыми данными «легко и просто», но это всего лишь иллюзия жизни в чистенькой однопоточной вселенной.
Мир клиентских приложений далеко не так структурирован и регулярен. Типичное клиентское приложение выполняет сравнительно небольшое количество вычислений для одного конкретного пользователя, поэтому параллелизм используется в основном для разбиения этих вычислений на более мелкие части. Эти части, скажем к примеру, пользовательский интерфейс (UI) и программные вычисления, взаимодействуют и разделяют между собой общие данные мириадами различных способов. Основные причины, которые делают этот тип приложений сложными для параллельного исполнения это: неоднородный код, высокая гранулярность, сложные взаимодействия и структуры данных, основанные на указателях.
Комментариев нет:
Отправить комментарий