JAVA , многоядерность и мультипроцессорность

356ft85

Подскажите, что известно по сабжу.
Для си++ всё более чем понятно мне - это MPI , OpenMP.

SPARTAK3959

Знания new Thread synchronized, volatile, wait, notify, notifyAll достаточно для решения большинства задач связанных с многопоточностью. В более сложных случаях могут пригодится классы из java.util.concurrent.*. С кластерами я пока не связывался - поэтому ничего кроме использования Socket'а для распараллеливания на несколько компьютеров не знаю.

katrin2201

Знания new Thread synchronized, volatile, wait, notify, notifyAll достаточно для решения большинства задач связанных с многопоточностью. В более сложных случаях могут пригодится классы из java.util.concurrent.*.

Ну только я бы сказал, что сначала скорее пригодится concurrent api, и только потом уже в более сложных случаях wait/notify/notifyAll.

pitrik2

все что ты перечислил это аналоги pthread
автор же ищет аналоги MPI

katrin2201

все что ты перечислил это аналоги pthread
автор же ищет аналоги MPI

не понятно, чего автор хочет, название топика путает

pitrik2

не понятно, чего автор хочет, название топика путает

помойму все ок
мультипроцессорность - когда у тебя несколько процессоров
MPI позволяет потоки запускать на разных процессорах
подозреваю что в MPI есть всякие фичи для управления этим делом, например : гарантированный запуск второго потока на другом процессоре
в java Thread этого точно нельзя сделать, там второй поток запустится где повезет, может на другом процессоре а может и на этом же
но насколько я помню, MPI он несколько не для этого
он больше для кластеров, т.е. когда у каждого процессора еще и память своя
и там были всякие фичи типа пересылки данных с памяти одного проца в память другого

agaaaa

подозреваю что в MPI есть всякие фичи для управления этим делом, например : гарантированный запуск второго потока на другом процессоре
в java Thread этого точно нельзя сделать, там второй поток запустится где повезет, может на другом процессоре а может и на этом же

Я всегда думал, что это ОС занимается выбором процессоров под потоки.

katrin2201

MPI - Message Passing Interface - позволяет взаимодействовать процессам, живущим вне одной ОСи, возможно даже живущим на ОСях разных семейств.
Смысла пользовать какую то реализацию MPI внутри одной ОСи как правило нету, ибо у этой ОСи есть своя нативная реализация взаимодействия процессов.

conv3rsje

Смысла пользовать какую то реализацию MPI внутри одной ОСи как правило нету

Зачастую есть, например, если система с 2x4 ядра и какая-нибудь вычислительная задача, написанная под MPI
Переделывать прогу никто не будет, а считать быстрее хочется.
Upd
Опять же, про оси разных семейств, это утопия. Если прога не занимается кодированием/декодированием данных в нейтральный формат

katrin2201

Зачастую есть, например, если система с 2x4 ядра и какая-нибудь вычислительная задача, написанная под MPI
Переделывать прогу никто не будет, а считать быстрее хочется.

Это не смысл. Это ты вынужден так поступать.
Мы же говорим об осознанном выборе библиотеки взаимодействия процессов.

katrin2201

Опять же, про оси разных семейств, это утопия. Если прога не занимается кодированием/декодированием данных в нейтральный формат

Это не утопия, это просто никому не нужно, ибо бессмысленно.
Но потенциально - возможно. Это я и хотел подчеркнуть.

conv3rsje

Мы же говорим о выборе библиотеки взаимодействия процессов.

Тогда надо весьма четко оговаривать среду, в которой должна прога работать.
Ибо без этого выбор библиотеки бессмысленен
А про взаимодействие разных МПИев, у меня есть очень большие сомнения, что разные реализации совместимы.
Поскольку mpi накладывает ограничение лишь на API, а не на реализацию
Разные реализации одного мпия на разных системах могут работать только при соответствии размеров типов и порядка бит (LE, BE)
Более того, это очень тяжело реализовать из-за схемы, которая в МПИ используется для запуска, поскольку бинари будут разные.

katrin2201

Тогда надо весьма четко оговаривать среду, в которой должна прога работать.
Ибо без этого выбор библиотеки бессмысленен

Бинго. Именно поэтому постановка задачи автором меня мягко говоря смущает.

А про взаимодействие разных МПИев, у меня есть очень большие сомнения, что разные реализации совместимы.

Да, они как правило несовместимы. Разве я утверждал обратное?

Filan

Тогда надо весьма четко оговаривать среду, в которой должна прога работать.
Ибо без этого выбор библиотеки бессмысленен

Бинго. Именно поэтому постановка задачи автором меня мягко говоря смущает.

Есть мнение, что жаве на всё это положить.

katrin2201

Есть мнение, что жаве на всё это положить.

на что на все?
на джаве есть несколько реализаций mpi, старое и новое конкаррент апи, и еще туева хуча гораздо более специфичных либ-велосипедов
чтобы из всего этого выбрать что-то подходящее, надо понимать, то ли чуве хочет кластер веб-серверов, то ли хочет параллелить чмы какие-нить, то ли дистрибутед.нет свой написать

schipuchka1

мультипроцессорность - когда у тебя несколько процессоров

у меня есть некоторые подозрения, что платформонезависимый язык не должен иметь механизмов привязывающихся к железу, максимум что-то можно сделать через обращения к виртуальной машине.
Я таких возможностей, во всяком случае, не видел

Filan

Вобщем почти ответил за меня.
Вы тут спорили о разных платформах (железо/ОСь) и как будет это всё работать вместе. Так вот для жавы эти все вопросы не актуальные (если есть jvm для всех этих платформ).
Важнее другой твой вопрос:

и еще туева хуча гораздо более специфичных либ-велосипедов
чтобы из всего этого выбрать что-то подходящее, надо понимать, то ли чуве хочет кластер веб-серверов, то ли хочет параллелить чмы какие-нить, то ли дистрибутед

Но даже этот вопрос рано пока задавать - по первому посту понятно (по крайней мере мне что автор вообще ничего не знает о подобных реализация в жаве, поэтому спрашивает ключивые слова. Так что вы забегаете вперёд. А если знаешь эти реализации mpi - подскажи. А целесообразность будем обсуждать, когда автором будет выкурено хоть чуть-чуть доков. :-]

katrin2201

Но даже этот вопрос рано пока задавать - по первому посту понятно (по крайней мере мне что автор вообще ничего не знает о подобных реализация в жаве, поэтому спрашивает ключивые слова. Так что вы забегаете вперёд.

Я все это прекрасно понимаю. Вся дискуссия развилась уже не в ответ на непосредственно вопрос автора.

А если знаешь эти реализации mpi - подскажи.

На вике все доходчиво расписано.

А целесообразность будем обсуждать, когда автором будет выкурено хоть чуть-чуть доков.

Я уже, честно говоря, наобсуждался =)

katrin2201

у меня есть некоторые подозрения, что платформонезависимый язык не должен иметь механизмов привязывающихся к железу, максимум что-то можно сделать через обращения к виртуальной машине.

К сожалению, дыры в абстракции есть. Например JNI.
Как ни странно, одна из самых популярных реализаций MPI для JAVA написана как JNI обертка к сами-угадайте-чему.

schipuchka1

К сожалению, дыры в абстракции есть. Например JNI.
Как ни странно, одна из самых популярных реализаций MPI для JAVA написана как JNI обертка к сами-угадайте-чему.

ну извините, если использовать JNI, то это будет уже не совсем программа на жабе. да и вообще его использование считается плохой практикой, как и GOTO в паскакале\С

klyv

а по мне, так для создания качественных кроссплатформенных библиотек без него не обойтись.
а если обходиться, то библиотека будет медленной (если она хоть чуток требует ресурсов).
конечно, использовать JNI для чего ни попадя нехорошо, и лучше делать сперва обёртку, а потом использовать только неё, но технология эта необходима.

katrin2201

ну как тебе сказать
swt, tomcat - это первое что в голову пришло
В этих проектах jni пользуется весьма осознанно
В томкете правда небольшой необязательный кусочек, но тем не менее, рекомендуемый.
В mpijava оно там, конечно, я почти уверен, от желания сэкономить, не переписывая всю реализацию. Но как бы уж лучше такое, чем совсем никакое.