Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.11.08 07:27
Оценка: +1 :)
Здравствуйте, WFrag, Вы писали:
S>>Впервые слышу про NUMA в Java.
WF>http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
Бугога. И какое отношение это имеет к заявлениям DenysSG? Каждый объект по-прежнему существует в единственном экземпляре; никаких репликаций не выполняется.
За что люблю этот форум — так за то, что если пропустил comedy club в субботу, так тут не дадут заскучать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 08:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DenysSG, Вы писали:


DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.

S>А где можно прочитать про этот адский отжиг?
S>Впервые слышу про NUMA в Java.

Сейчас нету времени искать, но должно быть здесь
Threads and Locks
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary

S>Бугога. И какое отношение это имеет к заявлениям DenysSG?

Тогда зачем было спрашивать про NUMA в Java, если то-что-описал-DenysSG — это не NUMA?
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:30
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Сейчас нету времени искать, но должно быть здесь

DSG>Threads and Locks

Что-то мне подсказывает, что это всего лишь модель.
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:35
Оценка:
Здравствуйте, WFrag, Вы писали:

DSG>>Сейчас нету времени искать, но должно быть здесь

DSG>>Threads and Locks

WF>Что-то мне подсказывает, что это всего лишь модель.


Да, и причем это модель памяти предыдущей версии Java (JLS 2): http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

В третьей редакции упоминания о разделяемой и локальной памяти нет.
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.11.08 08:53
Оценка: -1 :)
Здравствуйте, DenysSG, Вы писали:
DSG>Сейчас нету времени искать, но должно быть здесь
DSG>Threads and Locks
Естественно, там ничего относящегося к твоим фантазиям нету.
Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 09:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Естественно, там ничего относящегося к твоим фантазиям нету.

S>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
S>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
S>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.

Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Re[10]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 09:17
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Sinclair, Вы писали:


S>>Естественно, там ничего относящегося к твоим фантазиям нету.

S>>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
S>>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
S>>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.

WF>Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.


Вообщем, я нашел то что имел ввиду
http://www.intuit.ru/department/pl/javapl/12/3.html

Читайем раздел Хранение переменных в памяти.

Думаю, официальный материал должен быть в
http://java.sun.com/docs/books/jvms/
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 09:31
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Вообщем, я нашел то что имел ввиду

DSG>http://www.intuit.ru/department/pl/javapl/12/3.html

DSG>Читайем раздел Хранение переменных в памяти.


DSG>Думаю, официальный материал должен быть в

DSG>http://java.sun.com/docs/books/jvms/

Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Re[12]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 09:39
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, DenysSG, Вы писали:


WF>Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.


Да, так и есть. Вообщем, я то про это тут топик и не заводил.
Это Nicht`у будет полезно почитать про то что он имел ввиду.
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 19.11.08 09:59
Оценка:
Здравствуйте, remark, Вы писали:

R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.


А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо)
А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает
Я даже слово волшебное знаю, пожалуйста
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.11.08 10:25
Оценка: 15 (1) +2
Здравствуйте, yumi, Вы писали:

R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.


Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.


Демагогия.

Проектов, которые на универсальных императивных языках реализуют модель актеров, не так уж и мало. Для Ruby -- Revactor, для Java была сделана SEDA, для Scala -- ScalaActors, для Python -- Eventlet и Kamaelia.

R>>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).


Y>Напиши. Вся проблема в том, что ты этого не напишешь.


Вы пытаетесь брать "на слабо" не того человека. Ему и не нужно писать это самому, вокруг достаточно велосипедостроителей, которые делают уже это. При этом широко используя знания и идеи remark-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.08 11:43
Оценка:
Здравствуйте, cadet354, Вы писали:

C>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?


В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.08 11:55
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG> А в Java создание потока — ресурсоемкая операция.


Зеленые потоки в Джаве доступны уже давно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.11.08 12:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Зеленые потоки в Джаве доступны уже давно.
В любом случае использование пула потоков однозначно решает проблемы стоимости создания. А уже зеленые потоки в пуле или красные — дело второе.
От этого, по идее, зависят только накладные расходы на переключение с потока на поток.
Если у нас выполняется могучий поток мелких задачек, то расходы на переключение можно свести к минимуму путем банального ограничения размера пула. В предельном случае на N-ядерной машине в пуле ровно N потоков, которые никогда не вытесняются, а постоянно вытаскивают задания из очереди и никогда не засыпают (кроме случаев отсутствия входящих задач).
Зеленые потоки помогают только в том случае, когда мы реально выполняем в потоке длинную операцию с периодическими засыпаниями в синхронном ожидании события.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 12:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.

и как там таски обмениваются между собой сообщениями ?!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:23
Оценка:
Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, remark, Вы писали:


R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего*

назначения, они вообще ни по какому пути не идут. Они просто
предоставляют *все* возможности. Хочешь — пиши в разделяемую память,
хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и
пиши функции без побочных эффектов.

Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения,

тоже теоретически доступны *все* возможности. А вот на практике, увы
совсем другая картина.

Не понял смысл аналогии с ассемблером. Давай более конкретно. Вот
константный объект сообщения, который я передаю между потоками:
msg const* m = new msg (...);

Это С++. Что тут не так?
Вот функция без побочных эффектов, которая используется при распараллеливании:
void func(int* a, int* b, int begin, int end)
{
  for (int i = begin; i != end; ++i)
    a[i] += b[i];
}

Какие тут проблемы?


R>>В контексте "языки общего назначения vs языки специального

назначения" нельзя упускать из виду тот факт, что "практически любая
фича/идея/модель будучи реализована в языке специального назначения
достаточно тривиально реализуется и в языке общего назначения"
(вольный перевод, по-моему, Страуструпа).

Y>Также нельзя упускать из виду, что Эрланг тоже язык общего

назначения. Насчет "достаточно тривиально" очень спорное утверждение.

Мммм... ну и как в Эрланге работать с общей памятью?
Реализация фич определенно требует некоторого времени, но что сложного, например, передавать неизменяемые объекты между потоками? или писать функции без побочных эффектов? или сделать очередь передачи сообщений и работать в модели актёров? По своему опыту могу сказать, что всё это достигается легко. Никаких проблем не встречал.


R>>В чём проблема использовать в С++/C#/Java *уже существующие*

библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою
библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет
ряд существенных достоинств. Особенно учитывая, что любой вменяемый
проект на языке общего назначения в любом случае включает некую
начальную стадию по созданию подходящего "нижнего слоя" для всего
остального "мяса" приложения).

Y>Напиши. Вся проблема в том, что ты этого не напишешь.


Мммм... даже не знаю, что ответить... Разве что я уже две написал. И работал с рядом проектов, которые активно использовать передачу сообщений, хотя и до актёр-ориентированных не дотягивали.
Написать рабочую базовую версию — на это надо примерно 1 день. А дальше полная свобода действий. Хочешь вставляешь логирование всех проходящих сообщений, хочешь делаешь специальную фильтрацию при широковещательных рассылках, хочешь делаешь перехватчики сообщений, хочешь делаешь диспетчиризацию при отправке, хочешь при получении, хочешь делаешь reader-writer агенты и т.д.


R>>Так же можно привести такой пример. Допустим в программе есть некий

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

Y>Переключение контекста очень дешевое, т.к. там легковесные потоки.


Там всё дешевое. Пара дешевых переключений, пара дешевых созданий сообщений, пара дешевых удалений сообщений, пара дешевых добавлений сообщений в очередь, пара дешевых доставаний сообщений из очереди. А в сумме? Максимум, чего они могут достичь при данной семантике это примерно 100 тактов на сообщение, а скорее 300-500. А если у нас запрос-ответ, то 600-1000. Это влияет на то, что вообще можно выносить в асинхронную обработку. Например, если у нас сама полезная операция занимает ~100 тактов, то накладненько получается её делать асинхронной и привлекать передачу сообщений.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:29
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели.

DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.

Вполне можно представить и ситуацию, когда "старая" многопоточная Java программу будет работать быстрее, ну не в 32, но допустим в 20 раз. И в тоже время "старая" Erlang программа будет работать медленнее. Автоматического линейного увеличения производительности никто не даёт.

DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.


Отсюда следует только один (уже хорошо известный) вывод — просто не надо часто создавать потоки. Точка. Проблема решена.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: Gajdalager Украина  
Дата: 19.11.08 12:56
Оценка:
Здравствуйте, remark, Вы писали:


R>Вот функция без побочных эффектов, которая используется при распараллеливании:

R>
R>void func(int* a, int* b, int begin, int end)
R>{
R>  for (int i = begin; i != end; ++i)
R>    a[i] += b[i];
R>}
R>

R>Какие тут проблемы?

То, что здесь есть побочные эффекты, проблемой не является?
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:58
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>remark,


R>>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.


LCR>В случае Эрланга дедлок совсем не смертелен


Смертелен или не смертелен — это другой вопрос. На С тоже делают программы, любое отклонение от нормальной работы в которых, не смертельно. В любом случае, дедлок — это ошибка, которая в последствии требует исправления. И получить её в Эрланг можно.


LCR> — потомушта процесс сохраняет возможность принимать другие сообщения. В том числе и те сообщения, которые вызовут badmatch с последующим перезапуском процесса (а мы же строим приложение на принципах OTP). Это кардинально отличается от замёрзшего на вайте потока.


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


LCR>Кроме того, в случае Эрланга есть эффективный и надёжный способ анализа программы на счёт отсутствия дедлоков: Towards a deadlock analysis for Erlang programs. Хотя возможно и для обычных джавы и дотнета есть подобные тулзы.


Наличие тулзов скорее говорит о наличии проблемы, а не о её отсутствии.


R>>Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.


LCR>Не мог бы ты проиллюстрировать сиё подробнее. Всегда считал, что как только мы пишем receive, то тем самым задаём явное упорядочение.


Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.