Параллельные вычисления - разные бывают. Для чего-то сгодится Лисп, поддерживающий треды, для чего-то - Erlang, для чего-то - Parallel Haskell...

Что то мне казалось что у них производительность небольшая по сравнению с С++? Есть ли смысл юзать функц. язык и пихать это на кластер, если та же производительность на С++ у тебя получиться на локальной машине? :-)

Может приведете ссылки на тесты сравнения?

Fortran90 [Fortran95].
C.

1) Это тебе именно что КАЗАЛОСЬ. Всё у них в порядке с производительностью.

2) Гораздо проще прогаммировать - а время разработки - это тоже деньги.

1) Извините, ну очень голословное утверждение Ваше.... я вот таких языков) (что бы были навороченно-фукциональные и по производительности не отставали от С++) не знаю... хотя вроде как параллельными вычислениями занимаюсь. Можно примеры конкретных проектов? Не только мне но иширокой общественности интересно.

2) все зависсит от задачи. Если время разаработки много больше времени счета - то да. А если наоборот? А если время счета входит во время разработи следующих версий кода задачи?

Вообще параллельные вычисления весьма широкая область. Надо на задачу смотреть... основной подъем производительности происходит за счет правильного АСИНХРОННОГО алгоритма. Для реализации параллелизма в С есть MPI, я думаю что она (ее оболочки) есть практически везлде... и основнгой проблемой являеться как раз не реализация всяки параллельных приблуд, а разработка правильного алгоритма и его высокоээфективная реализация в рамках одного узла. Что опять таки приводит нас к С/С++... Или Вы хотите сказать, что есить фунциональные языки которые по производительности не отстают от С? Допускают использование ассемблерных вставок? Простите, я Вам не поверю... пример, ример приведите пожалуйста.

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

Ну, к примеру, Erlang. В той области параллельных задач, где он применяется, заменить его на C++ - нереально. Вообще. В том числе и из соображений производительности - хотя на последовательном выполнении он от C++ отстаёт.

OCaml - очень быстрый, не медленнее C++, и, в принципе, неплохо параллелится. Его в числодробильне уже нехило применяют - хотя, IMHO, неуместно это.

Для всяких сложнючих эвристик (задачи оптимизации, генетическое программировние, сложные доказательства и верификация, да те же шахматы на крайняк) - Haskell рулит. Числа грызть в этих задачах не надо, а то, что надо делать - крутить всякие навороченные структурки данных - он умеет куда как лучше, чем C++.

Епрст........ с последним абзацем я согласен полностью, но не понимаю при чем здесь параллелизм. Едиственно что а-ля микрософт-вай - это работает охренительно медленно, но переписывать и вылизывать кодж мы не бум, а лучше пнем производителя - пущай поднимет мощность машины на порядок а мы привесим пару бантиков и итоговая производительность упадет вдвое. Так и Вы - давайте сунем это на кластер :-) Но впрочем такой подхот тоже обоснован, если время счета на одном релизе меньше времени разработки.

Но вот что значит "хорошо параллелиться"????????????????? Я не понимаю Причем здесь используемый язык? Или они средствами компилятора языка решили проблемы battle neck etc? и пользователю не нужно удже на эту тему париться? Не верю....... такие вещи очень задачезависимы. Может в хаскеле это и сделано для какого то класса задач, связанных с анализом сложных структур и т.д... но для тяжелого численного счета все что они могли сделать - скрытно для пользователя применить тупуой домайн декомпозишен лили что то в этом роде... для несамосоласованных задач это канает, но там все тривально и можно распараллелить руками. А обычный домайн декомпозишн не особо интересен, поскольку на больших кластерах выигрыша почти не дает....

Что касеться применимости для тяжелого счета чего то кроме С++ - как то это... во первыхх обратная совместимость. Во вторых, чиста идеологически, ИМНО ничего лучше С не придумать, если не меянть чего то принципиально на уровне железа. архитектуры и т.д. Возможно это инертность мышления....

Что же все таи в этих замечательнейших языках такого суперпараллельного? если несложно.... в двух словах.

Биляд... Ну сколько можно?!?

Ещё раз, медленно: параллельные вычисления - это НЕ ТОЛЬКО числодробильня. В числодробильне и C++ неуместен, гнать его ссаными тряпками - Фортран рвёт его, как Тузик грелку. Но есть и НЕЧИСЛЕННЫЕ параллельные задачи.

Так что, может эта, хватит дурнем прикидываться, а? Не смешно. Деццкий сад!

Разговор перешел на уровень детского садад, действительно....

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

Про медленно - МЕДЛЕННО прочитайте мой предыдущий постинг, а потом уже начинайте гнать волну. Я говорил не только про чиcлодробилки. Я задал конкретный вопрос - для нечислодробильных задач, где как вы сами сказали неважна производительность - зачем юзать многопроцессорные системы? И что это вообще за задачим? Я верю что они есть, и мне правда интересно - что это за звери...

И последнее - если вы не даете себе труда подписаться, то хотя бы фильтруйте базар. А если вы не можете держать себя в руках, и при этом не в состоянии ответить на конкретные вопросы... к модератору.

>Я задал конкретный вопрос - для нечислодробильных задач, где как вы сами сказали неважна производительность

Нет таких задач где не важна производительность :)

>зачем юзать многопроцессорные системы? И что это вообще за задачим? Я верю что они есть, и мне правда интересно - что это за звери..

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

Ну ёлы-палы, сколько можно тупить?!?

Есть задачи, где не важна производительность численных операций, но фатальна производительность, к примеру, операций поиска, выборки, создания и удаления сложных структур данных, и т.п. Более того - таких задач ГОРАЗДО больше в реальной жизни, чем числомолотилок.

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

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

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

К слову, я давным-давно уже не студент, увы...

2AIv:

Вы с анонимусом, похоже, о разном говорите.

Надо различать средства для параллельного программирования и средства для АВТОМАТИЧЕСКОГО распараллеливания.

Последнее, наверное, на функциональшину лучше ложится. Впрочем, учитывая "типический" фанатизм апологетов функционального программирования, вопрос остается открытым.

В каких *таких*?!? Про числодробильню - базара нет вовсе. Другие "такие" - дык много их, очень много разных. Мне тут что, монографию про технологии разпараллеливания писать? Если ты серьёзный человек - то сам на citeseer всё, что надо нашел бы. Если просто трепло пустое - то на хера мне тебе тут могзи лечить?

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

Так этому болвану тут и про то, и про другое рассказывали. И про message passing (то бишь, Erlang), и про автоматическое распараллеливание - то бишь, Parallel Haskell. Он - не догоняет. Глуп-с, однако. Глупцов лечить - смысла нет.

...

Да, вот эту тонкую разницу я не всегда улавливаю:-) Средства - это всякая шняга типа шредов, форков, MPI и т.д. наск я понимаю? У функциональных языков поди что то свое еще, у меня видимо воображения не хватает сообразить что именно. Но в той же MPI напр есть какие то элементы автоматизма - в том плане что она сама распихивает задачи по процессорам.

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

Спасибо.

...

>Про числодробильню - базара нет вовсе. Теперь уже нету? Раньше вы что то там пыталсиь сказать по этому поводу... Ладно, ОК.

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

Что касаеться тона ваших постингов........... " Лет триста назад .... -- за такие слова я пригласил бы вас на прогулку за город, где отряхнул бы вам пыль с ушей и проткнул насквозь."(с)

На сем общение с вами хотелось бы закончить.

Прошу прощения у общественности. Ну не смог удержаться, рука под вечер сама потянулась к стилусу....

Для {\bf \HUGE ДЕЛА "!"*MAX_INT} создавал проект
Функциональный Онаним
Он Лисп и Хаскель изучал
Фортран и С установил
На баше создавал скрипты
Цеплял винты - хранить сырцы
Подобьем Матрицы бЫли
Его скринсэйвы и скины.

В мудрость седых профессоров
Он облачал высокий лоб
С ним книга Пратта о былом
С ответом на любой вопрос
С ним верный Кнут - познанья столп
И ссылок полный каталог
С ним верный Vi что до поры
Лишь kill-ом закрывать он мог.

И он покинул localhost
Скитался в ftp-дали
Блуждал в неведомых портах
Куда пути его легли
Он направлял свой ясный взор
Прочь от обманчивых ++
От скрежетанья yandeх-а
И от контента ХХХ-ов.

И вот привел на край сети
Его скитаний тайный ход
Там перый же коннект загнал
Все нити разом в deadlock
Там кУрсор дыбил байтов вал
И бился яростно в окне
Ф.Онаним пути искал
Назад к покинутой ~/ ...

Еще раз сорри за такой бред на столь серьезном сайте:-)