LINUX.ORG.RU
 
atrus

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


0

1

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

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

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


[#] Ответ на: комментарий от anonymous 08.09.2011 15:59:24  
dizza

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

>Ты хрен найдешь объяву о вакансии с Коболом, но спец по Коболу зарабатывает в десятки раз больше тебя, сявки.

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

*** ()
[#]  

параллельность, прозрачная для программиста - не нужна

нужно руками вызывать pthread_create()/CreateThread()/или что там на целевой платформе. И мютексы-семафоры тоже руками. А если кодер все это не осиливает - значит, он не заслуживает того, чтоб его программы выполнялись параллельно

* ()
[#] Ответ на: комментарий от dizza 08.09.2011 20:21:59  

> Настоящие профи пишут на обыкновенных языках.

Настоящих профи ты даже издали не видел, такое чмо как к ним близко не подпустят.

> Потому, что профи он на любом языке - профи.

Профи выбирает адекватный инструмент под задачу. Поэтому языки профи - это Ада, Кобол и Фортран.

> Ты не знаешь сколько я зарабатываю

То, что ты убогий нищеброд - вполне очевидно.

anonymous ()
[#] Ответ на: комментарий от anonymous 08.09.2011 16:01:04  

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

Потому что ТС сказал: "шуточки в стиле Click, когда надо самому указывать что исполняется параллельно [...] не интересны".

***** ()
[#] Ответ на: комментарий от atrus 08.09.2011 22:32:11  

а откуда у Вас вдруг появилась уверенность насчет неспособности "зафиксать перфоркарту" ? Там не rocket science, древняя примитивная технология, параллельное программирование на порядки сложнее :)

* ()
[#] Ответ на: комментарий от atrus 08.09.2011 14:56:48  

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

Это да, но иначе вообще непонятно как.

Я не против, а даже наоборот. Но только делать это придётся в рантайме, что в принципе не так и сложно. К каждой ячейке привязать id потока и при доступе делать проверку. Но как уже говорили это может вдарить по производительности. Лично я такого языка не знаю. Да и расходы памяти, id на каждый байт, жирно.

** ()
[#] Ответ на: комментарий от atrus 08.09.2011 14:56:48  

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

** ()
[#] Ответ на: комментарий от shty 07.09.2011 17:34:55  
deterok

Если бы Линусу тоже самое сказали вы бы тут не сидели, так что на миллион велосипедов приходится один шедевр, вдруг TC навояет этот шедевр?

** ()
[#] Ответ на: комментарий от Harald 09.09.2011 4:15:53  
atrus

> а откуда у Вас вдруг появилась уверенность насчет неспособности "зафиксать перфоркарту" ?

Так надо ещё уметь их читать. А это уже навыка требует. :)

***** ()
[#] Ответ на: комментарий от Booster 09.09.2011 8:46:44  
atrus

> Это да, но иначе вообще непонятно как.

А вот по этому и интересуюсь - что там умные академики понавыдумывали. Потому что в реальные языки перекачёвывают удачные решения из академических.

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

> Сначала BIOS и операционные системы абстрагировали программы от ввода/вывода.

Лолшто?

> Потом умные указатели и сборщики мусора от памяти.

Все смешалось в доме Облонских. "Сборщики мусора от памяти" появились задолго до умных указателей.

> Следующий логичный шаг - абстрагирование от процессора.

Ты еще не знаешь, что уже можнго программировать не только в опкодах и инструкциях ассемблера?

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

Да-да, и твой кластер метапарадигм будет работать как на калькуляторе, так и на суперкомпьюетре, ога.

**** ()
[#] Ответ на: комментарий от Harald 08.09.2011 20:54:13  

>параллельность, прозрачная для программиста - не нужна

>нужно руками вызывать pthread_create()/CreateThread()/или что там на целевой платформе. И мютексы-семафоры тоже руками. А если кодер все это не осиливает - значит, он не заслуживает того, чтоб его программы выполнялись параллельно

А коммуникатор руками создать сможешь ? (:

***** ()
[#] Ответ на: комментарий от sS 09.09.2011 23:11:30  

> А коммуникатор руками создать сможешь ? (:

Какой именно коммуникатор? И насколько "руками"? Уточняй задачу, плиз :)

По готовой схеме, заказать печатную плату на заводе, напаять на нее микросхемы - запросто :) Разработать самостоятельно - теоретически тоже :) Только обойдется тебе такой хэнд-мейд коммуникатор на порядки дороже серийно выпускаемых )

* ()
[#] Ответ на: комментарий от Shimuuar 08.09.2011 15:33:42  
kyz

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

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

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

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

* ()
[#] Ответ на: комментарий от Harald 09.09.2011 23:34:11  

>Какой именно коммуникатор? И насколько "руками"? Уточняй задачу, плиз :)

>По готовой схеме, заказать печатную плату на заводе, напаять на нее микросхемы - запросто :) Разработать самостоятельно - теоретически тоже :) Только обойдется тебе такой хэнд-мейд коммуникатор на порядки дороже серийно выпускаемых )

Пацталом :)

Я конечно ожидал увидеть на ЛОР "спецов" в параллельном программировании но не до такой же степени :))

***** ()
[#] Ответ на: комментарий от sS 09.09.2011 23:52:00  

:))

я таки загуглил, и кажется понял, какой "коммуникатор" ты имел в виду,

и это - ненужная абстракция, на уровне вызовов операционной системы ее нет :)

* ()
[#] Ответ на: комментарий от anonymous 08.09.2011 16:01:04  

Действительно, почему никто OpenCL не обсуждает? Вроде бы это будущее программирования. Причем отнюдь не только "для специфичного параллелизма".

* ()
[#] Ответ на: комментарий от sS 10.09.2011 16:42:03  

о, я как раз сейчас подумываю об обновлении своего коммуникатора, написанного с использованием семафоров.
Может, посоветуете чего?
Мне он нужен для синхронизации нитей одного процесса, которые выполняются на одном физическом процессоре в многопроцессорной NUMA системе (установлены affinity).
Соответственно, основное требование, чтобы время синхронизации между нитями было порядка времени доступа к кэшу L3, т.е. ~50тактов.

* ()
[#] Ответ на: комментарий от Harald 09.09.2011 18:16:39  
atrus

> нафиг такие mad skillz, проще самому считыватель перфокарт спаять

Это в полной мере относится к вашему исходному утверждению.

***** ()
[#] Ответ на: комментарий от VLev 10.09.2011 12:21:31  
atrus

> Действительно, почему никто OpenCL не обсуждает?

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

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

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

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

** ()
[#] Ответ на: комментарий от VLev 10.09.2011 17:10:43  

Советовать какое-то готовое решение не зная тонкостей задачи тяжело. А вот посоветовать хорошую книжку по теме таки могу :)

Clay Breshears. The Art of Concurrency A Thread Monkey's Guide to Writing Parallel Applications

***** ()
[#] Ответ на: комментарий от sS 10.09.2011 22:07:10  

Да, книжка хорошая, спасибо. Буду студентам советовать.
Но мне в данном случае надо что-то куда более приближенное к конкретным реализациям актуальных библиотек на актуальном железе.
Надо будет доки по оптимизации на Intel/AMD освежить в памяти, а потом посмотреть как в pthread, omp и проч. основные синхронизирующие объекты реализованы.

>не зная тонкостей задачи

Да задача более-менее обычная. Алгоритм типа WaveFront, данные идут по конвейеру между нитями. Синхронизация нитей нужна, чтобы не допустить гонки данных и проч. нежелательных эффектов.
В идеале еще динамическую балансировку можно попробовать, но это только в том случае, если удастся достичь <100тактов на синхронизацию.

* ()
[#] Ответ на: комментарий от atrus 10.09.2011 20:53:06  

>никто не делает игрушки на чистом OpenGL, а использует более высокоуровневый движок
Дык все они как раз и используют OpenGL/DirectX, и вообще подобные проблемно-ориентированные фреймворки --- это не язык, а сленг.

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

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

* ()
[#] Ответ на: комментарий от Booster 10.09.2011 21:18:51  
atrus

> Программы делают под определённые/ограниченные мощности, если всё и так работает, то зачем оптимизировать дальше?

За тем же, зачем появилась понятие переносимости программ. С того момента, как производители упёрлись в потолок частоты, не дающий просто наращивать линейную производительность - возникает новый зоопарк. Увеличивается количество ядер, появляются неравноценные ядра, вроде Cell или тянущихся в процессор видеокарт.

А программисту всегда интереснее просто описывать машине задачу, не заморачиваясь на низкоуровневую возню. Более того, гипертрединг, в котором Intel виртаульно неравномерно разделяет ядро наводи на мысль, что в будущем процессоры могут вообще приобрести свойства ПЛИС, т.е. смогут из имеющихся вычислительных блоков динамически формировать нужное количество разнотипных ядер. Тут уже ручное создание/завершение потоков, делаемое каждым программистом лично становится вообще неуместным.

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

Это были примеры. Из разных опер, да. Сборка мусора как пример того, что когда-то обязательная операция была практически полностью взята на себя средой выполнения (runtime).

Ассемблерные вставки - как пример неуместности. Конечно, кое-где им ещё есть место, но не в прикладных программах.

***** ()
[#] Ответ на: комментарий от VLev 11.09.2011 11:57:22  
atrus

> Дык все они как раз и используют OpenGL/DirectX

Не, ну понятно, что опираются они как раз на них. Я просто думал, что не надо звать капитана Очевидность на каждую фразу. :)

***** ()
[#] Ответ на: комментарий от atrus 11.09.2011 16:44:26  

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

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

>т.е. смогут из имеющихся вычислительных блоков динамически формировать нужное количество разнотипных ядер.

Видеокарты пошли по этому пути, так что вполне реально.

>Это были примеры. Из разных опер, да. Сборка мусора как пример того, что когда-то обязательная операция была практически полностью взята на себя средой выполнения (runtime).

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

** ()
[#] Ответ на: комментарий от Booster 11.09.2011 19:50:00  
atrus

> Что насчёт драйверов к примеру?

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

> Меня забавляет, как некоторые несут какую-то технологию как знамя, не признавая ничего другого.

Верно, но это действует в обе стороны. Я помню времена, когда "религиозные войны" между сторонниками разных языков включали в себя обвинения типа: "А вот ваш язык X не пригоден для написания драйверов устройств". И самое забавное, что сторонники X обычно шли и искали способ написать драйвер. :) И никого не смущало то, что X ориентирован на разработку приложений для пользователей, а не системных компонентов.

***** ()