LINUX.ORG.RU

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


0

1

Интересуюсь какие сейчас есть императивные (т.е. Haskell не предлагать) языки программирования, приспособленные для параллельного программирования? Именно на уровне языка и желательно максимально прозрачно для программиста. Т.е. шуточки в стиле Click, когда надо самому указывать что исполняется параллельно или мега фреймворки для обычных языков, вроде C++, позволяющие создавать потоки и синхронизировать их работу - не интересны.

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

Спрашиваю именно потому, что знаю, что успехи на этом фронте не велики и хочется знать какая вообще там есть движуха. :) Википедию вроде смотрел. Что есть ещё?

★★★★★

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

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

shty ★★★★★ ()

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

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

jtootf ★★★★★ ()

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

Booster ★★ ()

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

Apple-ch ★★ ()
Ответ на: комментарий от dizza

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

dave ★★★★★ ()
Ответ на: комментарий от anonymous

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

dizza ★★★★★ ()
Ответ на: комментарий от dizza

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

lol

anonymous ()
Ответ на: комментарий от dizza

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

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

Deleted ()
Ответ на: комментарий от dizza

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

buddhist ★★★★★ ()
Ответ на: комментарий от dizza

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

Deleted ()
Ответ на: комментарий от dizza

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

Booster ★★ ()
Ответ на: комментарий от dizza

> Java. См. java.util.concurrent

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

note173 ★★★★★ ()

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

Booster ★★ ()
Ответ на: комментарий от ugoday

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

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

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

kyz ()
Ответ на: комментарий от ugoday

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

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

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

shty ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

dizza ★★★★★ ()
Ответ на: комментарий от shty

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

dizza ★★★★★ ()
Ответ на: комментарий от Apple-ch

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

dizza ★★★★★ ()
Ответ на: комментарий от Booster

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

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

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

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

Booster ★★ ()
Ответ на: комментарий от Booster

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

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

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

Дислексия?

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

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

Дислексия?

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

Booster ★★ ()
Ответ на: комментарий от Booster

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

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

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

ugoday ★★★★★ ()
Ответ на: комментарий от Booster

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

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

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

atrus ★★★★★ ()

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

Rakot ★★ ()
Ответ на: комментарий от ugoday

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

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

Booster ★★ ()
Ответ на: комментарий от atrus

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

Booster ★★ ()

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

Deleted ()

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

vertexua ★★★★★ ()
Ответ на: комментарий от Booster

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

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

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

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

atrus ★★★★★ ()
Ответ на: комментарий от kyz

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

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

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

Shimuuar ()
Ответ на: комментарий от dizza

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

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

anonymous ()

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.