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

EP>>Циклы бывают не только на низком уровне, но и на высоком. Ты же сам дальше и приводишь пример:
VD>>>Параллелить можно "в большом". Простой пример. В от есть у нас проект который мы разрабатываем. В нем 100500 файлов. Паралелить разбор одно фала практически бесполезно (очень сложно и мало толку). Но распараллелить разбор отдельных файлов можно довольно просто.
EP>>Вот как раз параллельный разбор отдельных файлов, это и есть цикл по файлам на высоком уровне — parallel transform/map, и может ещё и parallel reduce после, в зависимости от задачи.
VD>Это уже не циклы. Это уже структура программы.

А выражается эта СТРУКТУРА каким образом? Не циклами ли случайно?

VD>Паралеленье циклов чуть менее чем полностью бесполезно.

Если ты не все циклы циклами называешь, а лишь те которые не параллелятся, то видимо да. А если без терминологической эквилибристики — то вполне имеет, отсюда и видим в параллельных библиотеках (что multi-thread, что multi-process, что multi-node) примитивы "параллельных циклов" типа parallel map/transform, reduce, а иногда и сплавленные mapreduce.

VD>А для повышения эффективности и безопасности предоставить ему механизмы контроля передачи данных между параллельными процессам (или иными единицами параллельного выполнения).

Это только для подмножества тех задач, в которых требуется передача данных между параллельными процессами. Многие же задачи выражаются через mapreduce, где внутри процессов нет никакого взаимодействия с другими.
Те же задачи в которых имеется постоянное взаимодействие между процессами обычно относятся не к parallel computing, а к concurrent.