Сообщение Re[6]: Языки для распараллеленных вычислений от 02.08.2016 17:01
Изменено 03.08.2016 8:31 Evgeny.Panasyuk
Здравствуйте, VladD2, Вы писали:
EP>>Если ты не все циклы циклами называешь, а лишь те которые не параллелятся, то видимо да. А если без терминологической эквилибристики — то вполне имеет, отсюда и видим в параллельных библиотеках (что multi-thread, что multi-process, что multi-node) примитивы "параллельных циклов" типа parallel map/transform, reduce, а иногда и сплавленные mapreduce.
VD>Эти библиотеки точно так же бесполезны. Они не более чем костыли не решающие проблему, а только лишь незначательно их облегчающие.
Полезны, решают вполне реальные инженерные и научные задачи, причём успешно. Именно эти библиотеки и нагружают все вычислительные кластеры.
Ещё раз, речь про parallel computing, научных вычислениях и инженерных расчётах. Ты же вещаешь больше про concurrency — это другая тема.
VD>В плане языковых средств и библиотек можно выделить такие либы как Rx и ReactiveUI. Это более полезные костыли. И там нет никаких циклов.
VD>Но даже эти продвинутые костыли не решают проблему конкурентного изменения данных.
Во-во, о том и речь — это всё concurrency, и к сабжу имеет лишь опосредованное отношение
EP>>Это только для подмножества тех задач, в которых требуется передача данных между параллельными процессами. Многие же задачи выражаются через mapreduce, где внутри процессов нет никакого взаимодействия с другими.
VD>Это 100% задач. Все задачи требуют работы с данными.
Да, с данными, но далеко не все с разделяемыми данными.
EP>>Если ты не все циклы циклами называешь, а лишь те которые не параллелятся, то видимо да. А если без терминологической эквилибристики — то вполне имеет, отсюда и видим в параллельных библиотеках (что multi-thread, что multi-process, что multi-node) примитивы "параллельных циклов" типа parallel map/transform, reduce, а иногда и сплавленные mapreduce.
VD>Эти библиотеки точно так же бесполезны. Они не более чем костыли не решающие проблему, а только лишь незначательно их облегчающие.
Полезны, решают вполне реальные инженерные и научные задачи, причём успешно. Именно эти библиотеки и нагружают все вычислительные кластеры.
Ещё раз, речь про parallel computing, научных вычислениях и инженерных расчётах. Ты же вещаешь больше про concurrency — это другая тема.
VD>В плане языковых средств и библиотек можно выделить такие либы как Rx и ReactiveUI. Это более полезные костыли. И там нет никаких циклов.
VD>Но даже эти продвинутые костыли не решают проблему конкурентного изменения данных.
Во-во, о том и речь — это всё concurrency, и к сабжу имеет лишь опосредованное отношение
EP>>Это только для подмножества тех задач, в которых требуется передача данных между параллельными процессами. Многие же задачи выражаются через mapreduce, где внутри процессов нет никакого взаимодействия с другими.
VD>Это 100% задач. Все задачи требуют работы с данными.
Да, с данными, но далеко не все с разделяемыми данными.
Re[6]: Языки для распараллеленных вычислений
Здравствуйте, VladD2, Вы писали:
EP>>Если ты не все циклы циклами называешь, а лишь те которые не параллелятся, то видимо да. А если без терминологической эквилибристики — то вполне имеет, отсюда и видим в параллельных библиотеках (что multi-thread, что multi-process, что multi-node) примитивы "параллельных циклов" типа parallel map/transform, reduce, а иногда и сплавленные mapreduce.
VD>Эти библиотеки точно так же бесполезны. Они не более чем костыли не решающие проблему, а только лишь незначательно их облегчающие.
Полезны, решают вполне реальные инженерные и научные задачи, причём успешно. Именно эти библиотеки и нагружают все вычислительные кластеры.
Ещё раз, речь про parallel computing, научные вычисления и инженерные расчёты. Ты же вещаешь больше про concurrency — это другая тема.
VD>В плане языковых средств и библиотек можно выделить такие либы как Rx и ReactiveUI. Это более полезные костыли. И там нет никаких циклов.
VD>Но даже эти продвинутые костыли не решают проблему конкурентного изменения данных.
Во-во, о том и речь — это всё concurrency, и к сабжу имеет лишь опосредованное отношение
EP>>Это только для подмножества тех задач, в которых требуется передача данных между параллельными процессами. Многие же задачи выражаются через mapreduce, где внутри процессов нет никакого взаимодействия с другими.
VD>Это 100% задач. Все задачи требуют работы с данными.
Да, с данными, но далеко не все с разделяемыми данными.
EP>>Если ты не все циклы циклами называешь, а лишь те которые не параллелятся, то видимо да. А если без терминологической эквилибристики — то вполне имеет, отсюда и видим в параллельных библиотеках (что multi-thread, что multi-process, что multi-node) примитивы "параллельных циклов" типа parallel map/transform, reduce, а иногда и сплавленные mapreduce.
VD>Эти библиотеки точно так же бесполезны. Они не более чем костыли не решающие проблему, а только лишь незначательно их облегчающие.
Полезны, решают вполне реальные инженерные и научные задачи, причём успешно. Именно эти библиотеки и нагружают все вычислительные кластеры.
Ещё раз, речь про parallel computing, научные вычисления и инженерные расчёты. Ты же вещаешь больше про concurrency — это другая тема.
VD>В плане языковых средств и библиотек можно выделить такие либы как Rx и ReactiveUI. Это более полезные костыли. И там нет никаких циклов.
VD>Но даже эти продвинутые костыли не решают проблему конкурентного изменения данных.
Во-во, о том и речь — это всё concurrency, и к сабжу имеет лишь опосредованное отношение
EP>>Это только для подмножества тех задач, в которых требуется передача данных между параллельными процессами. Многие же задачи выражаются через mapreduce, где внутри процессов нет никакого взаимодействия с другими.
VD>Это 100% задач. Все задачи требуют работы с данными.
Да, с данными, но далеко не все с разделяемыми данными.