LINUX.ORG.RU
 
atrus

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


0

1

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

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

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


[#]  
shty
>>-----Цитата---->>

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

<<-----Цитата----<<

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

*** ()
[#]  
jtootf
>>-----Цитата---->>

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

<<-----Цитата----<<

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

***** ()
[#]  

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

** ()
[#] Ответ на: комментарий от dizza 07.09.2011 17:56:45  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 07.09.2011 18:21:26  
dave

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

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

***** ()
[#] Ответ на: комментарий от dizza 07.09.2011 17:56:45  
franchukroman
>>-----Цитата---->>

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

<<-----Цитата----<<

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

** ()
[#] Ответ на: комментарий от dizza 07.09.2011 17:56:45  
buddhist

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

*** ()
[#] Ответ на: комментарий от dizza 07.09.2011 18:39:20  
franchukroman

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

** ()
[#]  

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

** ()
[#] Ответ на: комментарий от ugoday 07.09.2011 22:31:24  
kyz

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

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

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

* ()
[#] Ответ на: комментарий от ugoday 07.09.2011 22:31:24  
shty
>>-----Цитата---->>

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

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

<<-----Цитата----<<

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

*** ()
[#] Ответ на: комментарий от franchukroman 07.09.2011 18:51:37  
dizza

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

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

*** ()
[#] Ответ на: комментарий от shty 07.09.2011 23:09:00  
dizza

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

*** ()
[#] Ответ на: комментарий от Apple-ch 07.09.2011 18:04:48  
dizza

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

*** ()
[#] Ответ на: комментарий от ugoday 08.09.2011 1:39:25  

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

** ()
[#] Ответ на: комментарий от Booster 08.09.2011 1:59:37  

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

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

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

Дислексия?

*** ()
[#] Ответ на: комментарий от ugoday 08.09.2011 2:01:50  

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

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

>Дислексия?

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

** ()
[#] Ответ на: комментарий от Booster 08.09.2011 2:11:17  

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

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

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

*** ()
[#] Ответ на: комментарий от Booster 07.09.2011 21:23:42  
atrus

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

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

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

***** ()
[#] Ответ на: комментарий от ugoday 08.09.2011 2:13:19  

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

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

** ()
[#] Ответ на: комментарий от atrus 08.09.2011 2:15:08  

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

** ()
[#]  
dimss

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

***** ()
[#]  
vertexua

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

*** ()
[#] Ответ на: комментарий от Booster 08.09.2011 8:37:58  
atrus

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

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

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

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

***** ()
[#] Ответ на: комментарий от kyz 07.09.2011 23:07:58  

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

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

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

()
[#] Ответ на: комментарий от dizza 07.09.2011 18:39:20  

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

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

anonymous ()
[#]  

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

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

anonymous ()