Создан новый язык программирования Armada для работы с параллельными вычислениями

Создан новый язык программирования Armada для работы с параллельными вычислениями
12.08.2020
14204

Группа исследователей под руководством доцента кафедры электротехники, вычислительной техники и компьютерных наук Университета Карнеги-Меллона, Брайана Парно опубликовала новый язык программирования Armada. Язык предназначен для формальной проверки высокопроизводительных параллельных программ.

Armada

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

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

Язык и инструмент под названием Armada были представлены в этом году на конференции по разработке и реализации языков программирования и получили награду Distinguished Paper.

Проверка для программиста

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

В настоящее время проверка орфографии выполняется автоматически. Постоянная проверка орфографии является примером «параллельного» программирования, в котором исполняемый файл выполняется одновременно с другими программами и вычислениями. 

Большинство программ сегодня представляют собой параллельные, – начиная с операционных систем и заканчивая множеством приложений: от обработки текста до просмотра веб-страниц.

«Armada разработана чрезвычайно гибкой, чтобы код было удобно писать каждому разработчику, и он работал как можно быстрее», – говорит Парно. «Но при этом программисты будут твердо уверены в том, что код будет правильно исполняться и ничего не испортит».

Возможности и перспективы

Благодаря C-подобному языку и семантике на основе конечного автомата с малым шагом, Armada дает разработчикам возможность произвольной компоновки памяти и примитивов синхронизации.

Чтобы «облегчить жизнь» разработчиков, Armada использует автоматизацию на базе SMT (satisfiability modulo theories) – задача разрешимости для логических формул с учётом лежащих в их основе теорий. А также библиотеку мощных методов рассуждений, включая гарантию на соответствие, обеспечение TSO (Total Store Order), сокращение и анализ псевдонимов. TSO – полностью упорядоченный доступ, когда процессор гарантирует, что операции доступа к памяти будут обращаться к основному ОЗУ в точности в том порядке, в котором закодированы.

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

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

Автор:
Обозреватель

См. также

Минцифры подготовило проект постановления по запуску платформы, на которой ИТ-специалисты могут пройти добровольное тестирование и подтвердить свою квалификацию.

11.12.2024    1038    user1915669    3       

2

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

03.12.2024    826    user2114475    0       

2

Российский Альянс по искусственному интеллекту обновил требования к специалистам по ИИ: вышла новая модель с основными профессиями и навыками. Теперь базовых профессий в сфере ИИ осталось только четыре.

01.11.2024    985    user1915669    0       

3

Система платежей «Волна» по планам сделает возможной бесконтактную оплату для владельцев IPhone в России, а BRICS Pay позволит совершать безналичные расчеты иностранцам по картам Visa и Mastercard.

23.10.2024    1300    AnastasiaKl    0       

4

Конструктор сайтов Wix уходит из России с 12 сентября 2024 года – перестанут работать все российский аккаунты. Сайты, привязанные к аккаунтам, также перестанут работать.

11.09.2024    1260    user1915669    2       

2

ИИ научат разработке цифровых интегральных микросхем – несколько российских научных институтов заявили об участии в проекте. Проект рассчитан на 3 года – с 2024 по 2026.

23.07.2024    894    user1915669    0       

2

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

18.07.2024    1010    AnastasiaKl    0       

1

В сентябре 2024 года видеоигры в России начнут маркировать – пока на добровольной основе. Геймерам будут сообщать о семи видах чувствительного (неприятного) контента в игре.

17.07.2024    1096    user1915669    0       

1

Комментарии

Инфостарт бот
1. Darklight 13.08.20 11:06 Сейчас в теме
Ну хоть бы пример кода что-ли привели бы?
MegasXXX; +1 Ответить
2. Perfolenta 13.08.20 14:23 Сейчас в теме
(1) вот тут кое что есть http://www.andrew.cmu.edu/user/bparno/papers/armada.pdf
не самый простой язык получился, но это только на беглый взгляд...
а вообще, скоро языков программирования будет больше, чем написанных на них программ... :)
я тут на днях в рамках тестирования Перфоленты написал на ней интерпретатор языка похожего на Scheme, но с полным набором встроенных функций Перфоленты и с многими аналогичными операторами...
назвал его Перфо :)... но самое смешное, что мне он даже понравился, чуть-чуть допилить и на нем даже можно что-то полезное делать, например умные конфигурационные файлы для программ на писанных на Перфоленте...
3. Darklight 13.08.20 18:02 Сейчас в теме
(2)Спасибо. С виду мне он не показался сложным - кстати, напомнил 1С Исполнитель - та же семантика типов справа через двоеточие, те же объявления переменных "var" и те же ключевые слова "method" для подпрограмм - на самом деле очень многое (кроме фигурных скобок для блоков кода и логических операторов) передрано из Oxygene (он же Pascal for .NET и Delphi Prism), даже оператор присвоения ":=" (и разделения программы на области Specification и Implementation).
Но я что-то пока не увидел там каких-то особых преимуществ для параллельного программирования. Всё это есть в том же Oxygene , С++, C#, Java - наверное что-то я пока упускаю из вида...
Код не могу назвать легко читаемым - по сложности он тяготеет к стилю программирования конца XX века (может просто из-за отсутствия подсветки синтаксиса по началу так тяжело его воспринимать даже мне - когда вообщем-то синтаксически он в больше степени удовлетворяет моим текущим предпотчениям, хотя нет - не текущим - уже прошлым - ибо такой синтаксис я уже мысленно перерос - теперь мой мозг оперирует "более простыми" синтаксическими конструкциями, но с повышенным уровнем абстракции программирования). Хотя синтаксис зыка Armada умещается чуть более чем в четверть страницы ;-)

Вот тут вставил код Armada из указанного документа-спецификации
SKravchenko; +1 Ответить
4. Perfolenta 13.08.20 19:13 Сейчас в теме
(3)
С виду мне он не показался сложным - кстати, напомнил 1С Исполнитель

Пожалуй, вы правы, я сначала не присмотрелся...
Скорее всего, вся соль в написании спецификаций, в которых надо писать разные правила вроде этого:
somehow modifies s ensures valid_soln(s);
Компилятор по этим спецификациям сделает проверки... а в остальном, кажется, надо самому использовать в коде примитивы синхронизации вроде mutex и операторы lock/unlock...
Я в Перфоленте сделал оператор Блокировка/КонецБлокировки и пока его думаю хватит для большинства реальных задач... остальные примитивы синхронизации буду реализовывать, если кто-то попросит или если сам увижу необходимость...
5. Darklight 14.08.20 09:31 Сейчас в теме
(4)Пока из специкифкаций кода языка Armada совсем не ясно - в чём их преимущество и что сделает компилятор. Читать спецификацию языка на английском мне влом - чувствую, всё-равно не разберусь в деталях скрытой логики - но что я вижу по коду мне не даёт никаких намёков на то, что в языке что-то есть особенное - полезное для параллельного программирования - чтобы его изучать и использовать - всё очень низкоуровнево.

Если вся суть в отдельных спецификациях - то и смысла делать отдельный язык не было никакого - достаточно было бы вы включить эти спецификации просто в доп инфо в любой(ым) существующим языкам (причём скорее - только в низкоуровневые типа C++ т.к. в высокоуровневых задачи параллельного программирования часто проще решаются через более высокий слой абстракции - и там эти спецификации не особо то и нужны) в виде расширения IDE и компилятора - и проверять код имеющихся языков на соответствие спецификации схемы параллельного программирования.

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

Если говорить о высокоуровневых методах синхронизации: я бы предложил асинхронные потоки - как источник ресурсов, и для обмена сообщениями; собственно обмен сообщениями между параллельными процессами; и асинхронные подписки на события, а так же асинхронных контролёров ресурсов (алёрты) - которые могли бы сами безопасно следить за величиной ресурса и формировать асинхронные события при выходе ресурса за лимит (при желании ещё и блокировать доступ к ресурсу - пока блокировка не будет снята отдельной командой).

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

Но в целом - я считаю, задача распараллеливания кода в высокоуровневых языках должна быть больше на стороне компилятора, чем программиста - компилятор должен сам решать - что и где он может распараллелить - а сам код должен выстраивать семантически таким образом - чтобы у компилятора было больше свободы в выборе реализации задач, поставленных программистом. А программист должен лишь указывать на нюансы взаимосвязей алгоритмов - когда нужно уточнить особенности синхронизации или последовательности выполнения операций
MegasXXX; +1 Ответить
6. Perfolenta 14.08.20 14:52 Сейчас в теме
(5)
Замечу, что для синхронизации одних блокировок не достаточно - да и, зачастую, они очень вредны

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

Круто бы так сделать, но мои рассуждения на эту тему пока не привели к чему-нибудь, что бы я мог бы внедрить в компилятор Перфоленты... была мысль сделать оператор Блок/КонецБлока (или Окружение/КонецОкружения), что бы программист мог отмечать в процедуре куски кода, которые не зависят от других кусков кода и которые можно запустить параллельно без вопросов, но что-то я пока не сложил это у себя в голове... надо придумать способы контроля, действительно ли код внутри блока не зависит от других...
7. Darklight 14.08.20 15:47 Сейчас в теме
(6)
Есть конечно случаи, когда блокировок не достаточно, но мне в реальной практике их всегда хватало...

Конечно же - можно выстраивать наверное 98% всех алгоритмов на блокировках - только когда они часто ставятся, а число параллельно выполняемых операций очень велико, как и велико число физических потоков - на которых они выполняются - то блокировки сразу становятся очень узким местом. Просто это очень тяжело почувствовать на простых примерах и на небольшом числе потоков. Просто дело уже ближайшего будущего сервера с сотнями ядер на борту (а во второй половине века уже с тысячами - на которые одновременно будут в секунду поступать тысячи и десятки тысяч небольших (и больших) задач) - затраты на блокировку ресурсов станут очень велики. А программисты ещё и склонны будут неэффективно их блокировать - чрезмерно задерживая работу с ними. Это плохое решение.

А если ещё рассмотреть гетерогенные вычленения (node.js и hadoop доступны уже сейчас) - то там вообще блокировки очень нелегко ставить - это априори самое узкое место в алгоритме будет - тормозящее всё и вся!

Та же проблема в 1С и СУБД - тут слишком много чрезмерных блокировок (ну если о них заботиться при использовании управляемых блокировок; а без них и подавно)! Зачастую - алгоритмы можно было бы встроить вообще почти без длительных блокировок (даже списание по партиям) - если бы в системе были специальные асинхронные неблокирующие операции работы с ресурсами! На самом деле 1С как раз работала в этом направлении - так появились разделители (сплиттеры) и так же появилась методика контроля остатков в конце транзакции (да даже учет через расширенную аналитику - это тоже из этой же оперы) - но это всё кустарщина - но она уперается в возможности СУБД.

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

А вы сравните скорость работы блокировок и атомарных функций в .NET Framework - правда для тестов нужно бы взять машину с как можно большим числом ядер - какой-нибудь сервер хотя бы с 40 ядрами и стартонуть на нём сотню-другую потоков (тасков)

В стандартной библиотеке Перфоленты у меня сделаны потокобезопасные коллекции

Кустарно на блокировках (как это предлагалось делать до .NET Framework 4) - или просто тонкие обёртки над потокобезопасными коллекциями платформы ".NET Framework"?

Кстати, ещё идея - сделать потокобезопасные переменные/свойства (ну например через атрибут "SafeThreadAttribute") - чтобы все операции над ними сразу превращались в потокобезопасные (атомарные или на крайняк с блокировкой - управлять этим должен компилятор)



(6)
задача распараллеливания кода в высокоуровневых языках должна быть больше на стороне компилятора, чем программиста

Круто бы так сделать

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

Ещё одной техникой может быть избыточная параллельность: когда в алгоритме есть много ветвлений, где вычисление условия ветвлений затратно - то можно параллельно запустить вычисление сразу нескольких ветвей и их условий - а потом уже слить вместе - по фактически вычисленному условию. Техника мощная - но чреватая: во-первых излишней нагрузкой, во-вторых - не должно быть побочных эффектов вычисления ложных ветвей, в третьих - подходит только для случая достаточно детерменированных алгоритмов (внутри ветвей); ну и вообще - это больше подходит интерпретаторам - где есть возможность проводить статистический анализ в runtime - хотя в будущем может ОС будут собирать статистику выполнения обычных программ - и оптимизировать их код при следующих запусках.

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

Надо это выводить статически при компиляции (как выведение типов) - но тут может быть много ошибок - у программиста должны быть средства по ручному указанию зависимостей! А так же простое средство анализа в IDE автоматически определённых зависимостей и просмотра кода - который будет выполнять параллельно (варианты представления тут могут быть различны - от цветового выделения потоков в строках кода, до формирования отдельных колонок-потоков со своими наборами инструкций и с местами их слияния).

Но всё же - если нужна высокая параллельность - инструкции изначально должны быть очень абстрактные - т.е. вместо инструкции, скажем "цикла" - должна быть инструкция - вызова специальной функции - которой передана коллекция (диапазон) обхода, функция (или целый набор функций с условиями применения) обхода (без сайд-эффектов), и отдельно указаны зависимости и алгоритмы с сайд-эффектами + доп опции. И уже тогда вызов такой специальной функции (ещё на стадии компиляции) должен будет проанализировать что ей дали и автосгенерировать алгоритм параллельной обработки - например она сначала запустить асинхронные операции фильтрации диапазона по условиям - а на выходе уже в отдельных потока параллельно начнёт обрабатывать данные подходящими функциями (уже без ветвления), отдельно обрабатывая зависимости и сайд-эффекты специальными защищёнными операциями)
8. Perfolenta 14.08.20 16:55 Сейчас в теме
(7)
то блокировки сразу становятся очень узким местом. Просто это очень тяжело почувствовать на простых примерах и на небольшом числе потоков.

Да, дело именно в этом, в современных массовых процессорах обычно не более 4-х ядер... даже если в коде установлено много блокировок, вероятность того, что хотя бы одна из них сработает очень маленькая... в моих тестах вероятность обычно была меньше, чем 1 к 1000000... имеются ввиду тесты на ошибку в многопоточном коде, без использования синхронизации... именно по этому я сделал вывод, что простой блокировки вполне достаточно, производительность не упадет в большинстве обычных программ... блокировки срабатывают крайне редко... однако, в программах где производительность критична, само создание Мьютекса уже может критичным... но это все же редкий класс программ...
Кустарно на блокировках (как это предлагалось делать до .NET Framework 4) - или просто тонкие обёртки над потокобезопасными коллекциями платформы ".NET Framework"?

да, как тонкие обертки...
если нужна высокая параллельность - инструкции изначально должны быть очень абстрактные

то, что вы предлагаете разумно, но я реализацию таких алгоритмов просто не потяну... это академическая задача, надо слишком много времени... а у меня это слишком больное место...
9. ivanov_alex 19.08.20 11:54 Сейчас в теме
При трудоустройстве будут сразу требовать опыт работы 5 лет, как у всех?

Оставьте свое сообщение