Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования,
т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
Во-первых, все мы знаем что закон Мура изменился: теперь производители процессоров начинают делать многоядерные решения.
К примеру,
Intel has a project called Keifer aimed at producing at a thirty two
core processor timed for the market in 2009/2010. Sun
already has an eight-core (with four hardware threads per
core) Niagra machine on the market today. Цитата из книги Programming Erlang, Joe Armstrong
Все мы знаем что в "параллельном мире" существуют 2 основные концепции:
— Shared memory
— Message Passing Interface (MPI)
Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java.
Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Особенно мне нравится философское видение вопроса тем же Армстронгом
We don’t have shared memory. I have my memory. You have yours.
We have two brains, one each. They are not joined together. To
change your memory, I send you a message: I talk, or I wave my
arms.
You listen, you see, and your memory changes; however, without
asking you a question or observing your response, I do not know
that you have received my messages.
This is how it is with Erlang processes. Erlang processes have no
shared memory. Each process has its own memory. To change the
memory of some other process, you must send it a message and
hope that it receives and understands the message.
To confirm that another process has received your message and
changed its memory, you must ask it (by sending it a message).
This is exactly how we interact.
Sue: Hi Bill, my telephone number is 45 67 89 12.
Sue: Did you hear me?
Bill: Sure, your number is 45 67 89 12.
These interaction patterns are well-known to us. From birth onward
we learn to interact with the world by observing it and by
sending it messages and observing the responses.
Теперь вопрос, что же будет дальше. 32 ядра от Интел в следующем или 2010 году — очень неожиданно.
И Java не очень-то готова.
А уже написанные приложения работающие с Shared Memory, как я понимаю,
еще в худшем положении, если возникнет потребность увеличить ресурсы и использовать все ядра.
Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java.
Другой вариант — многоязычное приложение, что, возможно, тоже не самое лучшее — ведь разные языки должны интегрироваться, и интеграция потребует затрат.
Нуууу эээээ, это похоже на то как какой-нить крестьянин заснул в 1900 году, потом проснулся в 1950 и сказал — "Ох$%ть!! Большевики!!?"
Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Машины для erlang пока сыроваты, но когда-нибудь и они займут свою нишу в production. Но мне кажется это будет просто отдельный критический функционал как JNI, а обвязка все равно будет на java или .net.
Здравствуйте, Aib, Вы писали:
Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
LV>Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
Конечно есть, я как раз о параллельных вычислениях написал.
Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Что-то я сомневаюсь что ресурсоемкая java программа с shared memory без модификации будет испльзовать все 64 ядра, если они действительно ей нужны будут.
Нужно использовать внешние библиотеки. В этом и проблема джавы.
Здравствуйте, DenysSG, Вы писали:
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
Есть еще STM (Software transactional memory) и использование полностью immutable data types.
DSG>А что ещё есть — Scala или Erlang через Jinterface Application.
Здравствуйте, DenysSG, Вы писали:
DSG>Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования, DSG>т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
DSG>Во-первых, все мы знаем что закон Мура изменился: теперь производители процессоров начинают делать многоядерные решения.
DSG>К примеру, DSG>
DSG>Intel has a project called Keifer aimed at producing at a thirty two
DSG>core processor timed for the market in 2009/2010. Sun
DSG>already has an eight-core (with four hardware threads per
DSG>core) Niagra machine on the market today.
DSG>Цитата из книги Programming Erlang, Joe Armstrong
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
DSG>Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java. DSG>Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Шаред то она шаред но все мы знаем что у потоков в java есть свое пространство памяти где и происходит в основном вся работа.
DSG>This is exactly how we interact. DSG>Sue: Hi Bill, my telephone number is 45 67 89 12. DSG>Sue: Did you hear me? DSG>Bill: Sure, your number is 45 67 89 12. DSG>These interaction patterns are well-known to us. From birth onward DSG>we learn to interact with the world by observing it and by DSG>sending it messages and observing the responses. DSG>[/q]
Так это же Compare And Swap. В java вполне себе присутствует. С учетом, опять же, собсвенных пространств памяти у потоков, java не сильно отличается от erlang.
Надеюсь в erlang так же аллегорично описывается атомарность изменения нескольких значений и поддержка данных up to date в нескольких "мозгах".
DSG>Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java. DSG>Другой вариант — многоязычное приложение, что, возможно, тоже не самое лучшее — ведь разные языки должны интегрироваться, и интеграция потребует затрат.
DSG>У кого какое мнение — высказывайтесь.
Вообще надо понимать что ноги многозадачности растут из архитектур процессоров. Вот есть сейчас в процессорах CAS, вот и везде он есть. Язык всего лишь предоставляет модель использования. Будет что-то другое вместо CAS и языки тоже модифицируются и модель ерланга не покажется уже такой красивой.
Как мне кажется, от многозадачности можно получить больше плюсов, когда ты ее используешь с умом, тоесть непосредственно для определенных задач. А в таком контексте все равно на чем программировать.
А в будущем ничего не поменяется. И 10 лет наза люди писали приложения которые работали на сотнях процессоров и ничего, справлялись. Просто серверные стойки будут меньше, шуму будет меньше, отдача температуры будет меньше. В общем к светлобу будущему движемся
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, DenysSG, Вы писали:
DSG>>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>>- Shared memory DSG>>- Message Passing Interface (MPI)
Y>Есть еще STM (Software transactional memory) и использование полностью immutable data types.
N>Так это же Compare And Swap. В java вполне себе присутствует. С учетом, опять же, собсвенных пространств памяти у потоков, java не сильно отличается от erlang. N>Надеюсь в erlang так же аллегорично описывается атомарность изменения нескольких значений и поддержка данных up to date в нескольких "мозгах".
Java и Erlang используют разные модели. Java — Shared Memory, Erlang — MPI.
Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков. Вообще подход написания другой.
В Java этого нету. В JVM поддержка multicore есть. В Java нужно писать explicit code используя сторонние библиотеки.
Здравствуйте, DenysSG, Вы писали:
DSG>Java и Erlang используют разные модели. Java — Shared Memory, Erlang — MPI.
Да, и ключивое слово тут модель. Просто сейчас erlang лучше передает модель синхронизации реализованных в севременных процессорвах. Прошу заметить, что тут я не пускаюсь в полемику так как просто не знаю erlang.
Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
DSG>Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков. Вообще подход написания другой.
А в erlang прям "Дивный новый мир". Простой пример. есть у меня адрес и индекс. Понятно что они всегда толжны соответствовать друг другу. Как в таком случае без синхронизации? (Пример гипотетический — так что не придерайся). Опять же, повторюсь что вся эта erlang модель в java да и везде, называется Compare and Set. Это сравнительно новая технология в процессорах позволяет менять данные не блокируясь на них. Там уже люди кучу алгоритмов напридумывали, который используются в java.util.concurrent на пример.
DSG>В Java этого нету. В JVM поддержка multicore есть. В Java нужно писать explicit code используя сторонние библиотеки.
Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам
И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Здравствуйте, DenysSG, Вы писали:
DSG>Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования, DSG>т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
Java давным давно позволяла писать многопоточные приложения, причем без использования сторонних библиотек. И так же давным давно Java использует все ядра, какие найдет в вашем процессоре, причем опять без использования сторонних библиотек и без каких-либо дополнительных настроек.
Что касается MPI — то это, скажем так, с одной стороны, некоторое конкретное апи, а сдругой стороны просто идеология. Тут, конечно, без сторонних библиотек не обойтись, причем есть готовые библиотеки для MPI в виде JNI оберток вокруг с-шных реализаций MPI, есть Pure Java библиотеки, реализующие MPI, и есть библиотеки, которые предоставляют аналогичный по смыслу сервис обмена сообщениями между потоками при помощи не-MPI апи. Конечно, нормальный MPI позволяет общяться не только ядрам в одном процессоре, но если рассматривать отдельно взятый компьютер, то передача сообщений между потоками сделана, очевидно, через ту самую общую памать.
Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Прикол в том что в Erlang не нужно писать код для распаралеливания.
Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.
Все что нужно сделать — придерживатся маленьких рекоммендаций.
Здравствуйте, Nicht, Вы писали:
N>Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
N>А в erlang прям "Дивный новый мир". Простой пример. есть у меня адрес и индекс. Понятно что они всегда толжны соответствовать друг другу. Как в таком случае без синхронизации? (Пример гипотетический — так что не придерайся). Опять же, повторюсь что вся эта erlang модель в java да и везде, называется Compare and Set. Это сравнительно новая технология в процессорах позволяет менять данные не блокируясь на них. Там уже люди кучу алгоритмов напридумывали, который используются в java.util.concurrent на пример.
Боюсь Вы совсем не понимаете, что такое Эрланг.
N>Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам N>И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Без поддержки виртуальной машины, это в принципе невозможно.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, Nicht, Вы писали:
N>>Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. Но в данном контексте, yumi прав, т.к. то что имеет ввиду Nicht не является решением проблемы.
Здравствуйте, Аноним, Вы писали:
А>Java давным давно позволяла писать многопоточные приложения, причем без использования сторонних библиотек. И так же давным давно Java использует все ядра, какие найдет в вашем процессоре, причем опять без использования сторонних библиотек и без каких-либо дополнительных настроек.
Ну дык, тогда уж и С++ это умеет. Да и вообще ОС сама масштабирует потоки на ядра. Речь-то ведь изначально совсем о другом шла...
А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
