Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DenysSG, Вы писали:
DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. S>А где можно прочитать про этот адский отжиг? S>Впервые слышу про NUMA в Java.
Здравствуйте, WFrag, Вы писали:
DSG>>Сейчас нету времени искать, но должно быть здесь DSG>>Threads and Locks
WF>Что-то мне подсказывает, что это всего лишь модель.
Здравствуйте, DenysSG, Вы писали: DSG>Сейчас нету времени искать, но должно быть здесь DSG>Threads and Locks
Естественно, там ничего относящегося к твоим фантазиям нету.
Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Естественно, там ничего относящегося к твоим фантазиям нету. S>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком. S>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются". S>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Sinclair, Вы писали:
S>>Естественно, там ничего относящегося к твоим фантазиям нету. S>>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком. S>>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются". S>>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
WF>Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, DenysSG, Вы писали:
WF>Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Да, так и есть. Вообщем, я то про это тут топик и не заводил.
Это Nicht`у будет полезно почитать про то что он имел ввиду.
Здравствуйте, remark, Вы писали:
R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо)
А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает
Я даже слово волшебное знаю, пожалуйста
Здравствуйте, yumi, Вы писали:
R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.
Демагогия.
Проектов, которые на универсальных императивных языках реализуют модель актеров, не так уж и мало. Для Ruby -- Revactor, для Java была сделана SEDA, для Scala -- ScalaActors, для Python -- Eventlet и Kamaelia.
R>>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
Y>Напиши. Вся проблема в том, что ты этого не напишешь.
Вы пытаетесь брать "на слабо" не того человека. Ему и не нужно писать это самому, вокруг достаточно велосипедостроителей, которые делают уже это. При этом широко используя знания и идеи remark-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали: AVK>Зеленые потоки в Джаве доступны уже давно.
В любом случае использование пула потоков однозначно решает проблемы стоимости создания. А уже зеленые потоки в пуле или красные — дело второе.
От этого, по идее, зависят только накладные расходы на переключение с потока на поток.
Если у нас выполняется могучий поток мелких задачек, то расходы на переключение можно свести к минимуму путем банального ограничения размера пула. В предельном случае на N-ядерной машине в пуле ровно N потоков, которые никогда не вытесняются, а постоянно вытаскивают задания из очереди и никогда не засыпают (кроме случаев отсутствия входящих задач).
Зеленые потоки помогают только в том случае, когда мы реально выполняем в потоке длинную операцию с периодическими засыпаниями в синхронном ожидании события.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
и как там таски обмениваются между собой сообщениями ?!
Здравствуйте, 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 тактов, то накладненько получается её делать асинхронной и привлекать передачу сообщений.
Здравствуйте, DenysSG, Вы писали:
DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели. DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
Вполне можно представить и ситуацию, когда "старая" многопоточная Java программу будет работать быстрее, ну не в 32, но допустим в 20 раз. И в тоже время "старая" Erlang программа будет работать медленнее. Автоматического линейного увеличения производительности никто не даёт.
DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Отсюда следует только один (уже хорошо известный) вывод — просто не надо часто создавать потоки. Точка. Проблема решена.
Здравствуйте, 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% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.