После того, как Google купил PeakStream появилось много заметок в духе "Google is evil". По слухам, команда пикстримовцев была раздроблена и программисты теперь разбросаны по разным проектам. Обидно это тем, что PeakStream делал интересный продукт в области параллельных вычислений, а теперь плодами их работы смогут насладиться не все желающие, а только Google. Вскоре после приобретения сайт www.peakstreaminc.com перестал отзываться. Его осколки можно еще наковырять в гугловском кэше. Ничего конкретного про технологию я там не нашла, так общие замечания.
В качестве основного конкурента PeakStream упоминается RapidMind и там с документацией все получше. Я немного почитала про то, что делает RapidMind, предполагаю, что PeakStream делал что-то в том же духе. RapidMind'овский продукт можно бесплатно скачать и опробовать, кстати. Но я пока ограничилась только чтением статей.
Идея этого всего состоит в автомагическом распараллеливании программы. Программист пишет код, который сам, без каких либо усилий со стороны программиста, пытается распараллелиться. Может распараллелиться на многоядерном процессоре. Может на GPU - прикинется, что его данные - это текстура и будет вычисляться на GPU. RapidMind для реализации этой затеи сделал нечто, что называет "параллельный язык программирования, встроенный в C++". Хорошо это все тем, что программисту не нужно задумываться в процессе написания о том, как именно это все будет распараллелено. Но придется научиться с этим параллельным языком программирования работать, на С++ он не похож. Работает это все с обычными C++ компиляторами.
Вообще интересно, насколько это удобно в работе и получит ли оно массовое распространение.
Не очень ясна эта затея, если честно...
ОтветитьУдалитьЕсли язык все равно не C/С++, то ради чего огород городить. Есть же куча ранее разработанных параллельных языков. А одним из достоинств функциональных как раз и считается легкость автоматического распараллеливания (когда нет побочных эффектов и правда делать легче).
В общем, не оценил я...
Не очень ясна эта затея, если честно...
ОтветитьУдалитьЕсли язык все равно не C/С++, то ради чего огород городить. Есть же куча ранее разработанных параллельных языков. А одним из достоинств функциональных как раз и считается легкость автоматического распараллеливания (когда нет побочных эффектов и правда делать легче).
В общем, не оценил я...
Нет, нет это не то распараллеливание. RapidMind предлагает распараллеливание в стиле SIMD (они называют это SPMD, single program multiple data). То есть массив данных обрабатывается реально параллельно, никакого квантования времени и т.п.
Вообще у разных языков дела тут обстоят по-разному. Виртуальная машина Эрланга умеет работать с гипертредингом и многоядерными процессорами (не знаю насколько хорошо). В Питоне (он, конечно, не функциональный, просто как пример языка со встроенной поддержкой многопоточности) вообще GIL (global interpreter lock), поэтому он не может работать с многоядерными процессорами.
Ну и задействование GPU в RapidMind - великая штука. Я не слышала ни про один функциональный язык, где бы пытались сбрасывать вычисления на GPU.
> Нет, нет это не то распараллеливание. RapidMind предлагает распараллеливание в стиле SIMD (они называют это SPMD, single program multiple data). То есть массив данных обрабатывается реально параллельно, никакого квантования времени и т.п.
ОтветитьУдалитьНу это типа Data Parallel Haskell
> Ну и задействование GPU в RapidMind - великая штука. Я не слышала ни про один функциональный язык, где бы пытались сбрасывать вычисления на GPU.
Это планируется сделать для Data Parallel Haskell в этом году, в одной из версий GHC. Я, правда, не знаю, в каком состоянии реально там сейчас обстоит дело... Но, видимо, какие-то наработки уже есть, раз упоминается об этом...
В Питоне (он, конечно, не функциональный, просто как пример языка со встроенной поддержкой многопоточности) вообще GIL (global interpreter lock), поэтому он не может работать с многоядерными процессорами.
ОтветитьУдалитьНет, вот это неверный вывод, вообще-то. Питоновский GIL сводит на нет преимущества многоядерности только при условии организации параллельной обработки тредами. Но при многопроцессной организации GIL не мешает. Именно поэтому такая большая область применения Питона как веб-программирование получает выигрыш от многоядерности автоматически, без малейших усилий со стороны программиста просто потому что веб-серверы работают в многопроцессной среде и так.
В юниксовом мире вообще зреет в последнее время идея, что сложность запихивания параллельной обработки в один бинарник с организацией тредов просто вообще уничтожает смысл этого подхода в целом. Плюсов-то не так уж и много.
<offtop>
ОтветитьУдалитьmaniak только забыл сказать что
при этом *слегка* возрастает потребление оперативной памяти ;)
(или скорее :( ) (чего только
стоит Django + Appache в multiprocess mode).
Особенно при условии что pyc & pyo
(в отличии от dll & so & pyd) файлы неэффективно "шарить" между процессами . И, также, все IPC становиться заметно медленнее,
хотя это можно обойти при наличии ровных рук.
</offtop>
По собственному опыту (>6 лет научных расчетов) могу сказать что все такие затеи заведомо мертвы. Подобные системы уже давно есть и толку от них очень мало - "тупы" они сильно. Именно поэтому все по-старинке используют MPI(2) и
"ручками" распараллеливают.
2Maniac:
ОтветитьУдалитьНет, вот это неверный вывод, вообще-то. Питоновский GIL сводит на нет преимущества многоядерности только при условии организации параллельной обработки тредами. Но при многопроцессной организации GIL не мешает.
Мы тут с Маньяком лично побеседовали, чтобы не было повисшего диалога, напишу итог здесь.
В Питоне не возникает проблем с работой с многоядерными процессорами, когда запускается несколько процессов и в каждом из таких процессов запускается свой интерпретатор Питона. Для веб-разработок это как раз то, что нужно.
Вообще так можно поступить с любым инерпретатором, любой виртуальной машиной. Запустить кучу процессов, в каждом из них по виртуальной машине, и вперед.
Меня же больше интересует распараллеливание в рамках интерпретатора и/или виртуальной машине.
2koder:
По собственному опыту (>6 лет научных расчетов) могу сказать что все такие затеи заведомо мертвы. Подобные системы уже давно есть и толку от них очень мало - "тупы" они сильно. Именно поэтому все по-старинке используют MPI(2) и
"ручками" распараллеливают.
Интерес к параллельным вычислениям очень возрос после публикации статьи Саттера The Free Lunch Is Over. Получается, что надо таки долбиться в эту дверь, потому что выбора особого нет...
> Интерес к параллельным вычислениям
ОтветитьУдалить> очень возрос после публикации
> статьи Саттера The Free Lunch Is
> Over. Получается, что надо таки
> долбиться в эту дверь, потому что
> выбора особого нет...
Я наверно не очень аккуратно написал.
От многопоточности никуда не деться. И для научных расчетов
SMP системы с 16 ядрами на общей памяти - давно стандартная ситуация. И что-бы 1)не усложнять
себе жизнь 2)Хоть как-то автоматизировать распарралеливание бородатые дядьки придумали нечто полуатоматическое. Это MPI(message pass interface http://en.wikipedia.org/wiki/
Message_Passing_Interface) - библиотека(точнее стандарт на интерфейсы, как BLASS/LAPACK), которая берет на себя всю низкоуровневую возню и предоставляет единый интерфейс независимо от архитектуры сиcтемы
(SMP/NUMA/Cluster), причем за более чем 30 лет использования ее интерфейсы и основные реализации "вылизали" просто неимоверно. +Компиляторы с ее(MPI) поддержкой(intel fortran/c,portland group f/c, etc) - вводятся диррективы типа #parralel #sync.
Полученная в итоге смесь позволяет
получать параллельную программу
весьма "малой кровью"(обычно ~3% от кода занимает код для параллелизации). А учитывая уникальную "разумность" MPI(раньше
эти библиотеки стоили десятки тысяч ненаших денег и писались *очень* аккуратно; в наследие мы получили Open MPI) полученная система показывает почти линейную масштабируемость на SMP (15 раз на 16 ядрах считается "не очень" результатом ) и вполне приличную на Cluster/NUMA. MPI умеет shared_memmory/pipes/unix_sockets /udp_sockets/... и автоматически выбирает наиболее оптимальный вариант в зависимости от конфигурации системы.
А вот ПОЛНОСТЬЮ автоматические проекты пока никаких практических плодов не дали.
P.S. Везде имеется в виду MPI2.
P.P.S. По поводу видеокарт -
CUDA(если кто еще не видел). NVidia не мудрствуя лукаво сдела
как и все остальные - спрятала всю параллельность/шейдеры "под капот"
а наружу выставила стандартные интерфейсы - BLAS + LAPACK + FFT.
И это IMO ПРАВИЛЬНОЕ решение, в отличии от YA Parralel PL.
Полученная в итоге смесь позволяет
ОтветитьУдалитьполучать параллельную программу
весьма "малой кровью"(обычно ~3% от кода занимает код для параллелизации). А учитывая уникальную "разумность" MPI
Я не работала с MPI, но слышала/читала. Жалуются люди на высокую сложность. Думаю поэтому сейчас такой интерес к Эрлангу.
Их вообще много, этих попыток автоматизации, насколько я погляжу: http://parallel.ru/tech/tech_dev/ifaces.html. На ThinkingParallel Майкл больше всего пишет про MPI и OpenMP, я так понимаю, это то, что наиболее популярно сейчас.
> Жалуются люди на высокую сложность
ОтветитьУдалить0_0. В C реализации MPI2
50 функции. Из них реально используются менее 15. Если через обертки для С++ то вообще 6 ф-ций,
(инициализация/закрытие коннекта)
а остальное в виде
mpi_stream << data1 << data2;
mpi_stream >> data1 >> data2;
Но на самом деле даже это не пишется - компиляторы типа intel icc по диррективам вставляют весь MPI код сами.