Наконец-то я увидел человека, который понимает, что Erlang не предназначен для больших вычислений.
Erlang лишь помогает написать параллельную программу, но нисколько не снимает с программиста задачу рассудительного анализа и определения, что в программе нуждается в распараллеливании, а что - нет, и как эти части и потоки будут между собой взаимодействовать.
Не "вроде как", а именно такие конструкции OpenMP в основном и призвана распараллеливать, нужно только отметить какий циклы нужно обработать так. Обычно компилятор с поддержкой OpenMP сам предлагает, какие циклы в программе можно распараллелить.
В таком случае это не даёт ничего нового по сравнению с существующими возможностями параллелизма в других языках, кроме другого подхода к разработке.
P.S. И снова я вижу эту странную цифру - миллион. Согласитесь, на 4х ядрах посчитать даже интеграл будет быстрее разбив его на 4 куска, чем на миллион и тратить время на их переключение/создание.
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено
Уже может, есть Intel Cluster OpenMP.
На прикладном уровне да, но в больших системах, когда на уровне продумывания рассчётов и минимизации пересылок всё продумано, никакого прироста в производительности Erlang не даст. В любом случае лимитирующим фактором будет являться время пересылки между узлами, даже в самых быстрых сетях.
И от этапа продумывания, на котором вычисления собственно и распараллеливаются никуда не деться, а если он пройден, то уже не столь важно на чём писать.
Только не стоит забывать, что это "распараллеливание" не совсем точное понятие и выполняться программа будет на отведённых для выполнения потоках.
Так что в итоге это не даёт каких-то особых преимуществ перед хорошо написанным кодом на C(++), кроме как включение параллелизма в концепцию языка. Но это избавление от сложности распараллеливания в C(++) наверняка имеет и недостатки в виде более сложной реализации некоторых вещей на Erlang'е.
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима
В общем случае не всякая "программа" может быть откомпилирована, а не всякая откомпилированная будет правильно работать, не так ли? Всё-таки C++ и Erlang вроде бы компилируемые языки, стоит смотреть больше на качестко и скорость работы полученного байткода, чем на время компиляции.
P.S. Я не против этого языка, но не нужно же считать его панацеей.
P.P.S. Мне даже уже интересно стало, если в Эрланге всё так не связанно друг с другом, то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков? :)
Мы же выше решили, что для HPC он не так уж и подходит, на данный момент пока что.
Я вижу его применение в основном для разнообразных "серверов", где нужно относительно небольшое(сотни?) число потоков, которые выполняют в один момент разные задачи, и без интенсивного обмена данными между собой. Хотя и остаётся вопрос, зачем для этого использовать именно Erlang :)
Согласен. Но где вы в моих постах увидели разговор про NUMA или распределённые системы с общей памятью? Я говорю про использование многоядерных процессоров, в которых можно не использовать пересылку сообщений, а использовать DMA к общей памяти на аппаратном уровне.
Думаю не стоит мешать в одну кучу всё многообразие существующих архитектур, в 09:59 я хотел сказать лишь о преимуществе (судя по переводу) OpenMP над Erlang на одной машине с множеством ядер, видимо это было не так истолковано :)
Так и думал, что все фразу про "очень много" не больше чем миф. И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами. Поживём-увидим, как будет идти распространиние Эрланга в массы :)
Erlang лишь помогает написать параллельную программу, но нисколько не снимает с программиста задачу рассудительного анализа и определения, что в программе нуждается в распараллеливании, а что - нет, и как эти части и потоки будут между собой взаимодействовать.
Совершенно наоборот, при современных размерах изображений распараллелить некоторые операции с ними вполне стоит и на десятки потоков.
А когда начнётся бум, программист на Erlang будет стоить соизмеримо с программистом на C.
P.S. И снова я вижу эту странную цифру - миллион. Согласитесь, на 4х ядрах посчитать даже интеграл будет быстрее разбив его на 4 куска, чем на миллион и тратить время на их переключение/создание.
Уже может, есть Intel Cluster OpenMP.
На прикладном уровне да, но в больших системах, когда на уровне продумывания рассчётов и минимизации пересылок всё продумано, никакого прироста в производительности Erlang не даст. В любом случае лимитирующим фактором будет являться время пересылки между узлами, даже в самых быстрых сетях.
И от этапа продумывания, на котором вычисления собственно и распараллеливаются никуда не деться, а если он пройден, то уже не столь важно на чём писать.
Так что в итоге это не даёт каких-то особых преимуществ перед хорошо написанным кодом на C(++), кроме как включение параллелизма в концепцию языка. Но это избавление от сложности распараллеливания в C(++) наверняка имеет и недостатки в виде более сложной реализации некоторых вещей на Erlang'е.
В общем случае не всякая "программа" может быть откомпилирована, а не всякая откомпилированная будет правильно работать, не так ли? Всё-таки C++ и Erlang вроде бы компилируемые языки, стоит смотреть больше на качестко и скорость работы полученного байткода, чем на время компиляции.
P.S. Я не против этого языка, но не нужно же считать его панацеей.
P.P.S. Мне даже уже интересно стало, если в Эрланге всё так не связанно друг с другом, то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков? :)
Я вижу его применение в основном для разнообразных "серверов", где нужно относительно небольшое(сотни?) число потоков, которые выполняют в один момент разные задачи, и без интенсивного обмена данными между собой. Хотя и остаётся вопрос, зачем для этого использовать именно Erlang :)
Думаю не стоит мешать в одну кучу всё многообразие существующих архитектур, в 09:59 я хотел сказать лишь о преимуществе (судя по переводу) OpenMP над Erlang на одной машине с множеством ядер, видимо это было не так истолковано :)