Линейное исполнение программы процессором – это неестественное явление. Правда, первые компьютеры фон Неймана и Тьюринга работали именно так. Это отчасти объяснялось тем, что даже на создание единственного процессора требовалось огромное количество ресурсов. В дальнейшем компьютеры продолжали работать линейно просто потому, что «так и должны работать компьютеры». И вот, хотя это и не совсем честно, но мы действительно учим тысячи людей мыслить так, чтобы они могли создавать линейные системы. Неудивительно, что после этого им сложно перестроиться и начать мыслить иначе.
Но одно из неотъемлемых свойств окружающего мира – это параллелизм процессов. В любом сообществе, компании и организации люди заняты в своей сфере и при необходимости контактируют с коллегами. Итак, откуда вся эта шумиха о том, что, дескать, очень сложно построить систему, которая будет одновременно работать с несколькими процессорами? И, тем более удивительно, что эта шумиха продолжается в современном мире встраиваемых систем, где уже многие десятилетия создаются системы с высоким уровнем параллелизма. Различные аспекты параллельного исполнения не обязательно выполнялись в конкретном многоядерном процессоре, и даже в нескольких образцах одной и той же процессорной архитектуры. Но, так или иначе, все проблемы, которые сегодня являются темой длительных ожесточенных дискуссий, уже решены в различных продуктах (счет экземпляров таких продуктов идет на миллионы).
Некоторые проблемы реализации программ на многоядерных устройствах связаны с выбором конкретной процессорной архитектуры, в частности, с тем, как именно процессор взаимодействует с программами. Например, решение Intel, в котором такая связь осуществляется через кэш-память, подвергалось критике. Причем, самый большой вопрос заключается в том, как такое решение можно масштабировать на десятки или даже сотни ядер. Такая компания, как Intel, пожалуй, найдет способ решить эту проблему. Но основная проблема – в людях: люди консервативны и, научившись определенному образу мышления, они не очень хотят что-то менять. Особый случай такого консерватизма мы видим в случаях, когда программист упорно выступает за использование того языка, на котором уже научился писать.
В настоящее время мы наблюдаем взрывной интерес к программированию параллельных систем. Отчасти этот интерес обусловлен позицией Intel: компания последовательно подчеркивает, что именно многоядерность позволяет повысить эффективность работы процессора, при приемлемом уровне потребления энергии. Кроме того, в наше время как грибы после дождя растут молодые компании, реализующие новые многопроцессорные архитектуры. Итак, мы стремимся найти все лучшие способы разработки новых систем, а также пытаемся приспособить современные и устаревающие программы к работе с такими новыми системами.
Сначала поговорим о проблеме устаревания. Не так давно мой коллега, Брайон Мойер, изучал, как одна голландская компания, «Vector Fabrics», разрабатывает мощные инструменты для анализа имеющегося кода и последующего запараллеливания этого кода для работы в виде нескольких потоков. Другие специалисты также пытаются делать это, но все они сталкиваются с законом Амдала. Этот закон формулируется так: «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента».
Действительно, проблема новизны при разработке программ очень актуальна. До сих пор, основные усилия были направлены на добавление параллельных конструктов в имеющиеся языки. В области встраиваемых систем таким языком, как правило, является C. Из-за этого возникают некоторые интересные проблемы, и язык C уже становится все более беспорядочным и путаным. Как правило, разработки сводятся к созданию подмножества языка C, в которое затем добавляются необходимые конструкты. Эти конструкты позволяют фрагментам кода на языке исполняться параллельно и обеспечивают связь (коммуникацию) между такими фрагментами. Но, при попытке разобраться в подобных языках, вы видите, что многие из них создавались с расчетом на использование на очень больших машинах, даже суперкомпьютерах – и совершенно не приспособлены для работы во встраиваемых системах. (А язык Handel-C был разработан для генерирования языка проектирования оборудования и по-прежнему используется при работе с FGPA – программируемыми пользователем вентильными матрицами).
Хорошо, и что дальше? Таккер Тафт, специалист из AdaCore, уверен, что знает ответ. Он считает, что мир просто нуждается в новом языке программирования. Более того, Тафт уже работает над подобным языком, который назвал «ParaSail».
Для справки – Тафт действительно знает, о чем говорит. Почти сорок лет назад он занялся системным программированием на первой машине с UNIX в Гарварде и является настоящим первопроходцем в этом деле. После этого он немало времени потратил на работу с языком Ada, в том числе, на решение довольно нетривиальной задачи: как написать компилятор для Ada на языке Ada? Ведь компилятор должен не просто компилировать, и Тафт начал встраивать в него аналитические инструменты, которые помогли бы оптимизировать работу. Эти инструменты помогали выявлять проблемы с кодом, и Тафт пытался донести эти проблемы до программистов. Впоследствии он перестал заниматься проблемами компиляции и сосредоточился на вопросах анализа кода. В основанной им компании, SoftCheck, удалось создать ряд инструментов для статического анализа кода на языках Ada и Java.
Одним из лицензиатов SoftCheck была компания AdaCore, которая встроила инструмент SoftCheck в свой продукт CodePeer. В начале 2012 года эта компания купила SoftCheck, назначив Тафта директором по языковым исследованиям. Тафт продолжил в новой компании свою работу над ParaSail (параллельным языком для спецификации и реализации).
Тафт начал работать над ParaSail, так как предвидел, что вскоре придут времена разработки систем с сотнями ядер. Он утверждает, что имеющиеся языки не просто вскоре окажутся неспособными к дальнейшей расширяемости и работе с таким количеством ядер. Гораздо хуже то, что во многих языках присутствуют феномены, принципиально не пригодные для работы на таком уровне параллелизма. К ним, в частности, относятся:
Глобальные переменные Глобальная куча со сборкой мусора Совмещение имен через параметры (parameter aliasing) Обработка исключений времени выполнения Явные потоки Явная блокировка/разблокировка Явное ожидание/сигнал Условия гонки
и хуже всего…
Указатели.
Если вы как-нибудь выберетесь с Тафтом перекусить и захотите спокойно пожевать, одновременно послушав умного человека – просто спросите у него, почему указатели не годятся для параллельной обработки. И послушаете, и накушаетесь досыта. Итак, в ParaSail отсутствуют как указатели, так и другие порочные конструкты из приведенного выше списка.
(Более подробно эти аргументы изложены в блоге ParaSail, где также можно скачать язык с библиотеками и узнать многое другое).
ParaSail разрабатывался так, чтобы с ним было легко освоиться любому, кому доводилось программировать на С++ или Java. Это объектно-ориентированный язык (указатели в нем заменены расширяемыми и сужаемыми объектами). Но основная характерная черта ParaSail заключается в том, что на нем сложно писать последовательный код, он сразу рассчитан на работу в параллельном режиме.
Разумеется, важнейшим элементом любого языка программирования является компилятор. Недаром Тафт так долго занимался разработкой компиляторов и инструментов для анализа кода. И компилятор ParaSail очень хорош в том, что касается проверки ошибок и отладки. В сущности, он является исключительно мощным и специализированным инструментом, совмещающим черты компилятора и анализатора кода. Он ищет и устраняет условия гонки, а также другие ошибочные условия времени исполнения, такие, как использование нулевых значений и неинициализированных данных, индексирование вне массива, числовое переполнение, висящие ссылки и т.д. Этот компилятор также создает сотни микропотоков, которые можно присваивать для исполнения множеству процессоров/ядер.
Неудивительно, что Тафт с большим энтузиазмом относится к ParaSail: ведь это его детище. Если хотите, можете подробнее познакомиться с этим языком и оценить, насколько он интересен вам в качестве инструмента для параллельной обработки. Но дело не только в том, какое будущее ожидает ParaSail. Пусть и с неохотой, но приходится признать, что для эффективной разработки программ для встраиваемых систем, где исключительно активно применяется параллельная обработка, нам просто необходим новый язык. Пытаясь и далее адаптировать существующие языки к парадигме параллельного программирования, мы действуем «задним числом». И программы, которые получаются в результате таких попыток, неэффективны и требуют интенсивной отладки, для которой пока не существует подходящих инструментов. Самое сложное заключается в том, что, признав эту необходимость, мы, возможно даем толчок развитию целого класса новых языков. И только добавляем неопределенности в процесс развития программирования, разжигая новые холивары.
Источник: Дик Селвуд, www.eejournal.com
Линейное исполнение программы процессором – это неестественное явление. Правда, первые компьютеры фон Неймана и Тьюринга работали именно так. Это отчасти объяснялось тем, что даже на создание единственного процессора требовалось огромное количество ресурсов. В дальнейшем компьютеры продолжали работать линейно просто потому, что «так и должны работать компьютеры». И вот, хотя это и не совсем честно, но мы действительно учим тысячи людей мыслить так, чтобы они могли создавать линейные системы. Неудивительно, что после этого им сложно перестроиться и начать мыслить иначе.
Но одно из неотъемлемых свойств окружающего мира – это параллелизм процессов. В любом сообществе, компании и организации люди заняты в своей сфере и при необходимости контактируют с коллегами. Итак, откуда вся эта шумиха о том, что, дескать, очень сложно построить систему, которая будет одновременно работать с несколькими процессорами? И, тем более удивительно, что эта шумиха продолжается в современном мире встраиваемых систем, где уже многие десятилетия создаются системы с высоким уровнем параллелизма. Различные аспекты параллельного исполнения не обязательно выполнялись в конкретном многоядерном процессоре, и даже в нескольких образцах одной и той же процессорной архитектуры. Но, так или иначе, все проблемы, которые сегодня являются темой длительных ожесточенных дискуссий, уже решены в различных продуктах (счет экземпляров таких продуктов идет на миллионы).
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.