[ЖЖ]Императивные параллельные языки

А это смотрел?

http://wotug.org/parallel/languages/

http://www.cs.cmu.edu/~scandal/parallel-lang/reading-list/reading-list.html

знаю, что успехи на этом фронте не велики

думаешь именно «великов» не хватает?

Фортран

Ada

Haskell

надо самому указывать что исполняется параллельно

в той или иной мере это всегда приходится делать. к счастью

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

SystemVerilog

Java. См. java.util.concurrent

Есть еще Ada, но она мертва.

Еще C#, но это оффтопик.

Erlang

Нет, спасибо. Буду изучать.

Scala вроде подходит под описание.

Эрланг не императивный, учи матчасть, Стив!

> Есть еще Ada, но она мертва.

Видимо твой летчег на ватарке не подсказал тебе, что почти все программное управление на авиалайнерах на Аде написано.

> Erlang

Школьнег

возможно Go

> почти все программное управление на авиалайнерах на Аде написано.

На аэробусах. На боингах разве тоже? На наших вряд ли, хотя было какое-то исключение.

> На боингах разве тоже?

Yep.

У меня критерий живости языка очень простой: заходим на работный сайт и ищем вакансии. Их нет => язык мертв.

> заходим на работный сайт и ищем вакансии. Их нет => язык мертв.

lol

Есть еще Ada, но она мертва.

В 2005 зарелизен последний стандарт, в 2011 - последняя версия компилятора. Она еще живее всех живых.

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

Он бы еще сказал, что Кобол умер.

По вашим критериям живы только C, C++, C#, Java, полуживы - Delphi, VB, Python. То, что язык нужен не особо широкому кругу людей, не говорит, что язык мертв.

В С# многопоточность через фреймворк. Другой вопрос, нахрена она в самом языке. Так же другой вопрос если это сделано неявно.

> Java. См. java.util.concurrent

Не то. Немного похожа обработка коллекций в скале через .par. , но это все-равно явное указание.

Объясните как такое возможно. Какого уровня интеллект должен быть у транслятора, чтобы он смог определить что процедуру можно выполнить параллельно? Конечно имеются ввиду не тривиальные случаи, так как если он будет работать только на тривиальных, то это не стоит гроша.

Какого уровня интеллект должен быть у транслятора

Примитивного, если писать чистые функции.

>> Какого уровня интеллект должен быть у транслятора

Примитивного, если писать чистые функции.

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

> Какого уровня интеллект должен быть у транслятора

Примитивного, если писать чистые функции.

если чистые - то вообще никакого интеллекта не надо

Причём здесь чистые? На чистых и дурак сделает. Топ о чём, в курсе?

То, что язык нужен не особо широкому кругу людей, не говорит, что язык мертв.

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

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

А мне Erlang видится сильно гибридным. Посылка сообщения - сайд эффект, причем чем-то сродний присваиванию. Ну то есть посылка сообщения есть явное изменение состояния системы (прям как в ооп посылка сообщения) и это вполне себе императивная фича.

Причём здесь чистые?

На них проще паралелилизм организовать.

Топ о чём, в курсе?

Где вы здесь увидели противоречие?

Откуда транслятор узнает, что функция чистая? Из статического анализа? Уверены что не ошибётся? У меня такой уверенности нет. Да и вообще всё это малополезно. Подгонка функций к сферическому коню, малейший шаг в сторону и расстрел.

Откуда транслятор узнает, что функция чистая?

Например, ему это можно сообщить явно.

Подгонка функций к сферическому коню, малейший шаг в сторону и расстрел.

Дислексия?

>Например, ему это можно сообщить явно.

Почитайте требования в нулевом посте.

Дислексия?

Может быть, но у меня такого диагноза нет.

А вариантов всего два в данном случае:

• явное указание;
• анализ кода.

Если ты не хочешь ни того, ни другого, то ты круто тупишь.

> В С# многопоточность через фреймворк. Другой вопрос, нахрена она в самом языке. Так же другой вопрос если это сделано неявно.

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

Мой интерес в этом топике основан на простой интерполяции: Сначала BIOS и операционные системы абстрагировали программы от ввода/вывода. Потом умные указатели и сборщики мусора от памяти. Следующий логичный шаг - абстрагирование от процессора. И я говорю не о байткоде, это пройденный этап. Подобно тому как сейчас программиста зачастую не особо заботит как его данные лягут в память (он просто использует средства языка и стандартной библиотеки, потому что эти вопросы уже решены близким к оптимальному способом и отступление от него требуется только в особых случаях), так и в обозримом будущем не должно быть проблемой сколько и какого типа вычислительных ресурсов доступно. Сколько есть столько и должно использоваться.

OpenMP. Не язык, конечно, но обычные программы с его помощью параллелятся достаточно легко.

>Если ты не хочешь ни того, ни другого, то ты круто тупишь.

Я здесь при чём? Вопрос больше теоретический. Моё мнение что статический анализ это тупиковый подход.

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

Ada. Здесь многозадачность действительно является частью языка.

  task type Encapsulated_Buffer_Task_Type is
     entry Insert (An_Item : in  Item);
     entry Remove (An_Item : out Item);
  end Encapsulated_Buffer_Task_Type;
  ...
  Buffer_Pool : array (0 .. 15) of Encapsulated_Buffer_Task_Type;
  This_Item   : Item;
  ...
  task body Encapsulated_Buffer_Task_Type is
     Datum : Item;
  begin
     loop
        accept Insert (An_Item : in  Item) do
           Datum := An_Item;
        end Insert;
        accept Remove (An_Item : out Item) do
           An_Item := Datum;
        end Remove;
     end loop;
  end Encapsulated_Buffer_Task_Type;
  ...
  Buffer_Pool(1).Remove (This_Item);
  Buffer_Pool(2).Insert (This_Item);

Подробнее здесь:

http://en.wikibooks.org/wiki/Ada_Programming/Tasking

Сейчас во многие языки добавили parallel collections. Например в Scala. Но паралельно выполняются операции map, filter, потому это все же элемент ФП. Но в достаточно императивном языке. Вопрос в том, вам шашечки или ехать. Стоит впилить в императивный язык прозрачный паралелизм и вы чаще всего поймаете себя на мысли что перешли границу ФП

> Почему параллелить именно на уровне процедур, ведь это тоже ограничение?

Я ничего про процедуры не говорил. :)

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

Такой ответ для меня не удивителен. Я хорошо помню, как плевались на сборку мусора. Тоже куча народа заявляла, что только ручное управление - Ъ. :)

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

Data Parallel Haskell: http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

Но задача, действительно, очень сложная

> У меня критерий живости языка очень простой: заходим на работный сайт и ищем вакансии. Их нет => язык мертв.

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

Почему до сих пор никто не назвал Occam?

Ну и всякие там CUDA/OpenCL для специфичного параллелизма.