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

Потому что про него есть в википедии. :)

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

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

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

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

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

Мнение невежды, неспособного даже перфокарту зафиксать - не интересует. :)

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

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

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

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

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

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

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

ГСМ чтоле? Тогда все ясно. Знаток профей ты наш.

Насчет нищеброда анонимус то прав =)

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

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

Человек по определению не может быть прав с заявлениями типа «очевидно», «ты то-то» и т.д.

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

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

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

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

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

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

>Ада, Кобол и Фортран.
RIP

linux — шедевр? это что-то новенькое...

вдруг TC __навояет__ этот шедевр

Алишер Навои одобряет Вашу гражданскую позицию

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

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

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

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

> Так надо ещё уметь их читать

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

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

Лолшто?

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

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

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

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

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

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

> уже можнго

уже можно

Быстропочин.

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

Ой, какой толстенький. )))

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

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

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

Хмм ... что нибудь типа Co-array Fortran ?

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

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

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

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

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

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

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

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

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

Пацталом :)

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

:))

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

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

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

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

Школота жжот :))

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

Вы не хрена не поняли что я написал. Извините, но разжёвывать до вашего уровня мне лень.

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

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

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

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

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

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

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

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

> разжёвывать до вашего уровня мне лень.

Какая потеря! Жаль, что ты так и умрешь, непризнанным с моей стороны гением...

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

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

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

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

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

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

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

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

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

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

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

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

Я буду страдать, не смогу есть, буду плакать по ночам в подушку, но я обещаю: Я как-нибудь постараюсь пережить это.

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

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

php: http://ru2.php.net/manual/en/function.pcntl-fork.php

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

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

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

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

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

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

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

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

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

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

Спасибо, вы подсказали идеальный язык. Теперь - только на нём. :)