Здравствуйте, yumi, Вы писали:
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Наверное это для тебя новость но у потоков в джава есть свой личный кусок памяти. И он рабобтает в основном в нем. Ты никогда не задумывался зачем нужны volatile переменный и Atomic классы. Как раз для того что бы потоки обменивались изменениями в своих локальных пространствах памяти.
Еще раз спрашиваю, как на счет атомарности изменений и синхронизации данных. Пока апологеты erlang говорили только о том, что потоки обмениваются сообщениями. Это самая простая многопоточная программа. Как на счет того что несколько сообщения должны быть переданы атомарно и изменения должны быть видны во всех потоках? Если там так все без дедлоков, в чем я лично сомневаюсь, как на счет лайвлоков.
И тут говорили что в erlang ненадо писать код синхронизации. Тоесть надо предпологать что он рассылает эти ваши мессаги на каждый чих? Даже моего скромного ума хватит что бы понять, что такой подход сомнителен.
Y>Боюсь Вы совсем не понимаете, что такое Эрланг.
А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.
N>>Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам N>>И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Y>Без поддержки виртуальной машины, это в принципе невозможно.
Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Здравствуйте, Nicht, Вы писали:
N>А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.
Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?
Y>>Без поддержки виртуальной машины, это в принципе невозможно.
N>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Здравствуйте, abch-98-ru, Вы писали:
Y>>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
A9R>см. 4.2 там же и про race condition (поиском)
У меня щас тупо нету смотрелки pdf, связано ли это с shared memory? Ну конечно нет, т.к. в Эрланге нет shared memory Это как уж если приводить аналогии, то типа в средах с управляемой кучей не может быть утечек памяти, но все равно можно держать ссылки на коллекцию уже не нужных объектов
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Y>Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?
Да ты не обижайся. Я же не говорю что erlang плохой. Мне просто кажется что шапашного знакомства недостаточно для того что бы об этом рассуждать. И я высказывал лично сове мнение. Как в общем то и просил создатель темы.
Но, можно сказать что вы меня заинтересовали. Как раз хотел поразбираться с функциональными языками. Вот и почитаю.
Вот кстати на злобу дня Интервью с Армстронгом.
Y>>>Без поддержки виртуальной машины, это в принципе невозможно.
N>>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Y>Erlang avalanche
опять двадцать пять
Y>>>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
A9R>>см. 4.2 там же и про race condition (поиском)
Y>У меня щас тупо нету смотрелки pdf,
не катит. любой текстовый вьювер (да хоть less) проблему решит. Открываешь и ищешь 4.2. Поиском внутри файла учить пользоваться ?
Y>связано ли это с shared memory? Ну конечно нет, т.к. в Эрланге нет shared memory Это как уж если приводить аналогии, то типа в средах с управляемой кучей не может быть утечек памяти, но все равно можно держать ссылки на коллекцию уже не нужных объектов
Здравствуйте, yumi, Вы писали:
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.
Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.
Здравствуйте, yumi, Вы писали:
А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Y>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
Здравствуйте, DenysSG, Вы писали:
А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
DSG>Прикол в том что в Erlang не нужно писать код для распаралеливания. DSG>Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.
out of box получится что? Загрузить на 100% все 100 ядер/машин? Или добиться 100 кратного ускорения работы?
DSG>Все что нужно сделать — придерживатся маленьких рекоммендаций.
А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).
Здравствуйте, DenysSG, Вы писали:
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
Во-первых, никто не мешает их смешивать (с умом, естественно). Далее ещё есть Transactional Memory — сложно охарактеризовать, но определено не Shared memory... по сути получается вообще как однопоточное выполнение с кооперативным шедулингом (на логическом уровне, на физическом — по-прежнему параллельное исполнение). Далее — Data Parallel Programming — некого рода автоматическое распараллеливание (естественно с некоторым (возможно значительным) участием разработчика). Некоторые апологеты функциональных языков вообще говорят, что ФЯ в будущем дадут автоматическое распараллеливание (т.е. запускаем старую "однопоточную" программу, а она работает быстрее).
DSG>Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java.
Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
В контексте "языки общего назначения vs языки специального назначения" нельзя упускать из виду тот факт, что "практически любая фича/идея/модель будучи реализована в языке специального назначения достаточно тривиально реализуется и в языке общего назначения" (вольный перевод, по-моему, Страуструпа).
DSG>Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Ну это зависит. Во-первых, естественно для какой задачи. Во-вторых, как к этой Shared Memory подходить и как использовать.
Ну и надо учитывать тот факт, что сейчас оооооооооооочень много хайпа вокруг данного вопроса. Большинство из тех, кто говорит про это либо что-то продаёт, либо сам создаёт (даже "бескорыстное" академическое сообщество в большинстве своём создаёт какие-то конкретные модели и, естественно, описывают их приемущества, на описании "голой" разделяемой памяти понятно дело сейчас диссертацию не сделаешь).
Я ни в коем образе не говорю, что Shared memory — это superior модель. Наоборот я призываю смотреть шире, более объективно оценивать достоинства и недостатки моделей/языков, смотреть в корень, а не на малозначительные детали и т.д.
DSG>Теперь вопрос, что же будет дальше. 32 ядра от Интел в следующем или 2010 году — очень неожиданно. DSG>И Java не очень-то готова. DSG>А уже написанные приложения работающие с Shared Memory, как я понимаю, DSG>еще в худшем положении, если возникнет потребность увеличить ресурсы и использовать все ядра.
DSG>Решения, которые я нашел DSG>A Java Fork/Join Framework DSG>DataRush DSG>Что выглядит не очень привликательно.
А почему Fork/Join не очень привлекательно? АФАИК — должно войти/уже вошло в официальную спецификацию Java. Позволяет добиваться линейной масштабируемости для любого кол-ва ядер.
DSG>А что ещё есть — Scala или Erlang через Jinterface Application.
DSG>Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java.
В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
----------------
Теперь конструктивная часть.
Во-первых, надо определиться с классом задач. Одно дело — число-дробилки (моделирование, научные расчёты, обработка изображений, распознавание речи и т.д.), другое дело — неструктурированный параллелизм общего назначения (различное серверное ПО, системное ПО, клиентское ПО).
Для последнего *модель программирования* Erlang достаточно хороша. Основное, что тут надо учитывать:
(1) для разных приложений разная степень "достаточности". Для многих степень достаточности достаточная. Для некоторых — не очень. Ну и опять же вопрос — сколько мы хотим выжать из железа — 100% или 80% нам будет достаточно?
(2) *модель программирования* Erlang ни в коем случае не ограничена только самим Erlang'ом.
Для первого типа задач модель Erlang может как подходить и совсем нет. Для распределённых кластеров она, наверное, подходит, т.к. там обычно используют обмен сообщениями в том или ином виде. Для SMP/multicore, я думаю, в большинстве случаев модель разделяемой памяти подходит больше, т.к. ... ну т.к. это просто Shared Memory Processing.
Так же можно привести такой пример. Допустим в программе есть некий кэш данных (хэш-мап). В Erlang подходе мы этот хэш-мап отдадим одному процессу, и когда нам надо будет к нему обратиться будем посылать этому процессу сообщения. На физическом уровне это будет включать: создание объекта сообщения, помещение его в очередь, переключение контекста с текущего процесса, доставание сообщение сообщения другим процессом, обработку сообщения, удаление первого сообщения, создание сообщения-ответа, помещение сообщения-ответа в очередь, переключение контекста опять на первый процесс, доставание сообщения из очереди, удаление сообщения.
В модели с общей памятью мы... просто обращаемся к хэш-мапу.
Далее, что бы было понятно, что на самом деле эти модели имеют не такое уж и большое значение можно рассмотреть иерархию того, как они реализуются.
На нижнем уровне у нас транзисторы — разделяемая память.
На основе транзисторов многоядерные процессоры реализуют обмен сообщениями (будь то общие шины, либо соединения точка-точка).
Далее процессор реализует для программиста опять модель общей памяти.
На основе этого программисты делают библиотеки обмена сообщениями.
На основе библиотек обмена сообщениями реализуется DSM (distributed shared memory).
Распределённые кластеры, использующие DSM, объединяются на основе обмена сообщениями по глобальным сетям.
В глобальных сетях создаются системы управлениями объектами, которые позволяют работать с объектами "как с локальными" и пытаются поддерживать консистентность (shared memory).
...
Это действительно не столь принципиально, ты можешь использовать любую модель, можешь надстроить над любой любую, и всё равно в конечном итоге будешь использовать обе
Здравствуйте, remark, Вы писали:
R>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.
R>В контексте "языки общего назначения vs языки специального назначения" нельзя упускать из виду тот факт, что "практически любая фича/идея/модель будучи реализована в языке специального назначения достаточно тривиально реализуется и в языке общего назначения" (вольный перевод, по-моему, Страуструпа).
Также нельзя упускать из виду, что Эрланг тоже язык общего назначения. Насчет "достаточно тривиально" очень спорное утверждение.
R>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
Напиши. Вся проблема в том, что ты этого не напишешь.
R>Так же можно привести такой пример. Допустим в программе есть некий кэш данных (хэш-мап). В Erlang подходе мы этот хэш-мап отдадим одному процессу, и когда нам надо будет к нему обратиться будем посылать этому процессу сообщения. На физическом уровне это будет включать: создание объекта сообщения, помещение его в очередь, переключение контекста с текущего процесса, доставание сообщение сообщения другим процессом, обработку сообщения, удаление первого сообщения, создание сообщения-ответа, помещение сообщения-ответа в очередь, переключение контекста опять на первый процесс, доставание сообщения из очереди, удаление сообщения. R>В модели с общей памятью мы... просто обращаемся к хэш-мапу.
Переключение контекста очень дешевое, т.к. там легковесные потоки.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели.
Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
remark,
R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
В случае Эрланга дедлок совсем не смертелен — потомушта процесс сохраняет возможность принимать другие сообщения. В том числе и те сообщения, которые вызовут badmatch с последующим перезапуском процесса (а мы же строим приложение на принципах OTP). Это кардинально отличается от замёрзшего на вайте потока.
Кроме того, в случае Эрланга есть эффективный и надёжный способ анализа программы на счёт отсутствия дедлоков: Towards a deadlock analysis for Erlang programs. Хотя возможно и для обычных джавы и дотнета есть подобные тулзы.
R>Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.
Не мог бы ты проиллюстрировать сиё подробнее. Всегда считал, что как только мы пишем receive, то тем самым задаём явное упорядочение.
R>Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.
Здравствуйте, DenysSG, Вы писали:
DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели. DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
А Erlang автоматически будет, что ли? Это зависит от программы. Она может и на 1.5 процессоре в I/O упереться.
Непонятно, что именно нужно распараллелить и какие проблемы это сделать на Java, кроме общих слов? Пример какой-нибудь.
DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Есть пулы потоков. 100.000 потоков, конечно, не создавать, но чтобы загрузить 32 процессора — запросто (скажем, штук 200 потоков создать — и всех делов).
А вот интересно, если много ядер, то архитектура скорее всего NUMA. Erlang-машина это как-то учитывает? Не получится ли так, что обмен сообщениями убьёт производительность Erlang-программы, в то время, как неспешные 32 потока Java будут (каждый со своей областью памяти, локальной для процессора) осваивать процесорное время, выполняя полезные задачи?
Здравствуйте, DenysSG, Вы писали: DSG>Это интересно. До боли мне кажется что вы второй раз ошибаетесь. DSG>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты?
Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах.
В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DenysSG, Вы писали:
DSG>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.
А где можно прочитать про этот адский отжиг?
Впервые слышу про NUMA в Java.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. S>А где можно прочитать про этот адский отжиг?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DenysSG, Вы писали: DSG>>Это интересно. До боли мне кажется что вы второй раз ошибаетесь. DSG>>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты? S>Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах. S>В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.
Воообще Эрланг исходно можно было запустить на многоядерной машине, стартовав по ВМ на ядро.
При отстутствии явных грабель в коде (без закладок на то, что вся работа идёт внутри одной ноды), разница в коде минимальна (фактически минимальные связи между ВМ через конфигурирование).
Но теперь и SMP в Эрланге уже довольно неплохо работает (цифр под рукой нет), правда в следующих релизах ещё хотят улучшить.
Правда вполне может получиться что запуск нескольких ВМ даст большую производительность (SMP-версия всё же содержит некоторую часть разделяемых данных, а это боттлнек)
Здравствуйте, remark, Вы писали:
R>А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).
а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
