Многопроцессность vs Многопоточность и с чем их едят

> начальство утверждает, что распараллеливание обеспечит и сам планировщик БСД хорошее, а нам необходимо только написать многопроцессность, дабы раскидать выполняемый код по разным процессорам.

Начальство право. Нити могут дать выигрыш в том плане, что взаимодействие между ними гораздо дешевле.

Если я правильно понял этот поток сознания, то вам нужна именно многопоточность, а дальше планировщик сам раскидает. Он сделает это лучше, чем вручную потоки по процессорам раскидывать, я гарантирую это.

если это так то зачем придумали SMP IRQ Affinity? :)

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

> Не знаю как во фре, но в линуксе процесс и нить - это чрезвычайно близкие вещи.

Только по API для создания :)

> А шареная память в случае многопроцессности - это дешего, почти как общая в случае нитей.

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

ДАвайте введём уточнения, а то, похоже, народ запутался. Под многопоточностью я понимал multithreading, а вот как называецца мультипроцессность - я не знаю(почти все ссылки в интернете про мультипроцессорность, а не процессность).

Мы - за multithreading, а начальство за то, чтобы threadы сотворял планировщик, а мы только процессы распределяли по процессорам (т.е. полная копия всей программы на каждый процессор, которые взаимодействовали бы друг с другом каким - то образом).

Я так понял, что вы тоже за multithreading? Или таки нет?

>Только по API для создания :)
Эээ, я думал, что процесс и нить в линуксе отличаются только наличием собственной памяти. Ну и по мелочи.
>IPC по шареной памяти надо синхронизировать
Между процессами тоже надо.
>межпроцессная синхронизация стоит дороже
Незначительно.
>Переключение между процессами - тоже.
А между нитями? Я могу жостко ошибаться, поэтому прошу пнуть меня в нужную сторону, ссылки на доки, например.
>Да и обмен через шареную память не настолько удобен.
Ну, как сказать, в целом, ниразу не сложен.

Похоже, что поняли вы не совсем правильно.

Multithreading (многопоточность) - мы разбиваем код программы, который мы желаем распараллелить на потоки (threads) (скажем, цикл по обработке массива), а планировщик уже раскидает по процессорам эти потоки.

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

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

Я не понимаю как вы будете что-то писать, если даже в таких понятиях путаетесь. Процесс состоит хотя бы из одного потока(нити, в другой терминологии). Для десктоп приложений ,дабы процессоры не простаивали, обычно делают несколько нитей у одного процесса. Общение между потоками одного процесса обходится дешевле, чем общение между процессами. Однако есть программы, использующие процессы, так браузер Chrome на каждую вкладку запускает отдельный процесс. Таким образом обеспечивается бОльшая независимость(падение одного процесса не вызовет закрытия всех вкладок, большая безопасность т.к. отдельное адресное пространство и тд.). Сравнивать производительность без подробного описания задачи -- безумие, мы не знаем насколько интенсивный обмен данных между процессами/потоками, что по поводу безопасности и проч. и проч. В общем случае результаты по производительности где-то схожи.

Судя по тому, что Вы пишете, вам ещё рано писать многопоточные приложения. А поскольку задачу вам нужно решить уже сейчас, лучше пригласите стороннего программиста, он "распараллелит" вашу программу и объяснит вам, как он это сделал - конкретно в вашем случае.

Как вариант, можете попробовать разъяснить здесь, что ваша программа делает, с указанием способа взаимодейстия её блоков и времени, затрачиваемом каждым блоком. Вполне возможно, вам здесь помогут. Не обещаю.

Надеюсь, профайлером вы уже поработали и вся нужная статистика есть.

PS. Создавать потоки (или процессы) и давать им работу должны именно вы. Планировщик лишь обеспечит их выполнение на имеющихся процессорах. Скорее всего, в вашем случае потоки удобнее (и, как следствие, быстрее).

PPS. Многопроцессность и многопроцессорность - это, простите, вещи совершенно разные.

Фишка в том, что я не программер. Я строю математические модели на языках, типа Matlab и Python, разрабатываю сигнальные процессоры на HDL + чуточку играюсь с микроконтроллерами, поэтому для меня вообще тёмный лес написание программ под ОС. Мои подчинённые занимаются написанием программы и стоят за многопоточность, но, к сожалению, обосновывать такой выбор перед начальством нужно мне, а не им. Они же в свою очередь не хотят связываться с многопроцессностью, тк до этого работали только с многопоточностью. Поскольку я абсолютно доверяю в выборе своей команде, то мне необходимо до понедельника до 12 часов дня найти всю возможную информацию по данному вопросу, разобраться в нём и попытаться отстоять то, что желают делать мои подчинённые так, как они желают это делать.

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

Такой цикл работает порядка 3х-4х секунд, в зависимости от размера входного массива, что является недопустимым, тк система должна работать максимально быстро (в идеале - в реальном времени, чт соответствует 10 обработкам матриц входных значений в секунду).

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

Р.S Вы не совсем поняли. Я прекрасно понимаю, чем занимается планировщик, но плохо понимаю, что есть многопоточность и многопроцессность, поэтому и прошу оказать посильную помощь ссылками и идеями.

Р.Р.S. Я прекрасно понимаю, что многопроцессность и многопоточность - абсолютно разные вещи, но гугль меня не радует большим объёмом информации. Поэтому, я и просил хоть какие - нибудь ссылки по данному вопросу.

Р.Р.Р.S. Простите за неясность мысли и неточность изложения, но я очень давно не спал.

может openMP?

p.s. синхронизацию всё равно делать надо

> > Не знаю как во фре, но в линуксе процесс и нить - это чрезвычайно близкие вещи.

> Только по API для создания :)

По большому счёт, отличается только флагами в clone. Ну и потоки одной thread group принадлежат.

> Такой цикл работает порядка 3х-4х секунд, в зависимости от размера входного массива, что является недопустимым, тк система должна работать максимально быстро (в идеале - в реальном времени, чт соответствует 10 обработкам матриц входных значений в секунду).

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

Его мы и хотели бы использовать, но начальство против.

Ускорен максимально на уровне алгоритмическом. Прост, количество элементов в матрице за один замер - около 1,5е8. Подобраны оптимальные параметры GCC 4.2, подключены все инструкции, типа SSЕ 1:3, ММХ; BLAS и Lapack распараллелены при помощи OpenMP (об этом не было сообщено начальству), что привело к ускорению почти в 5 раз.

Компиляторы не умеют нормально векторный код генерировать, руками сильно лучше получается.

К сожалению такой роскоши, как руками, мы себе позволить не можем, тк крайне ограничены по срокам. БЫло бы больше времени, я бы не парился и написал сигнальный процессор, который бы делал задачу, потом заказали бы и вставили в PCIexpress и крутилось бы, но это мечта.

Итак, как я Вас понял:

У вас есть уже распараллеленная (!) программа, она работает 3-4 сек, а надо 0.1 сек. "Распараллеленная" (openMP) - видимо, значит многопоточная. Коли всё вылизали - значит, издержки на синхронизацию уже минимизировали (а т.к. ваша задача хорошо распараллеливается - значит, практически свели задержки к нулю). И, видимо, успешно загружаете все ядра системы (кстати, у вас что за железо?).

Итак, контрольный вопрос - вы уже все ресурсы компьютера использовали или нет?

Я понял что да. Что ещё вы хотите получить? Видимо, вам нужно докупить компов и объединить их в кластер? Тогда конечно, для того, чтобы решать задачу на кластере, надо запускать отдельные процессы на разных машинах, чтобы они договорились друг с другом и поделили работу. В таком случае вам придётся много возиться с передачей данных по сети (как с точки зрения программирования/использования готовых средств, так и с точки зрения скорости этой передачи).

В принципе, неплохо было бы, чтобы ваша команда подготовила подробное (техническое) обоснование, что они хотят и почему. И с этим обоснованием вы бы и пошли "наверх". Конечно, перед этим команде надо понять точку зрения начальства, чтобы подобрать понятные слова. Решать технические вопросы на нетехническом уровне чревато.

Попробую снова "от печки".

> начальство утверждает, что распараллеливание обеспечит и сам планировщик БСД хорошее, а нам необходимо только написать многопроцессность, дабы раскидать выполняемый код по разным процессорам

Одна из задач планировщика - раскидать потоки по процессорам. Надеюсь, БСД это умеет (как и все нормальные системы).

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

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

> Под многопоточностью я понимал multithreading, а вот как называецца мультипроцессность - я не знаю(почти все ссылки в интернете про мультипроцессорность, а не процессность).

Я всё так и понял.

> Я так понял, что вы тоже за multithreading? Или таки нет?

Я - ни за что. Зависит от задачи.

> Прост, количество элементов в матрице за один замер - около 1,5е8.

1.5e8 элементов размером 4 байта каждый дают 572мб. В рилтайме такой объём обработать на обычном, даже многопроцессорном, pc, по-моему, не удастся - память захлебнётся.

> Зависит от задачи.

...и эта задача напрашивается на multithreading.

> не удастся - память захлебнётся

уже на одних инструкциях mv ;-)

>> Прост, количество элементов в матрице за один замер - около 1,5е8.

> 1.5e8 элементов размером 4 байта каждый дают 572мб.

Железо редко поставляет 4-байтовые сущности. 1-2 байта - норма.

>>Только по API для создания :)

>Эээ, я думал, что процесс и нить в линуксе отличаются только наличием собственной памяти. Ну и по мелочи.

Мы не о Линуксе :) И даже в Линуксе это не совсем так. Процесс - это единица потребления ресурсов и отдельное защищенное адресное пространство.

>>межпроцессная синхронизация стоит дороже

>Незначительно.

В линуксе на фютексах - может быть (хотя цена переключения контекста между процессами всё равно никуда не девается).

>>Переключение между процессами - тоже.

>А между нитями? Я могу жостко ошибаться, поэтому прошу пнуть меня в нужную сторону, ссылки на доки, например.

Я думаю, в любой книге по устройству ядра обсуждается разница между процессом и нитью. Вот небольшой флейм на тему переключений контекста в том числе: http://www.linux.org.ru/view-message.jsp?msgid=3495441

>>Да и обмен через шареную память не настолько удобен.

>Ну, как сказать, в целом, ниразу не сложен.

В целом - сложнее, чем в одном процессе.

В принципе, вы меня поняли, но не совсем. У нас есть openMP (абсолютно верно - многопоточность) реализация математических библиотек (т.е. многие операции, которые возможно распараллелить, параллеляться [пример языком, который исключает неоднозначность, вследствии моей неграмотности: если операция y = a * b - b * c, то наша библиотека создаёт 2 потока, которые считают a*b и b*c, а потом потоки закрываются, а результат вычитается]), но не распараллелен сам внешний цикл по работе с матрицами, в котором и содержится несколько различных математических операций, в результате чего ядра загружены не на 100%, по 20% - 30%, тк в потоках только простейшие математические операции, которые идут поочерёдно.

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

Машина такая - http://www.dell.com/content/products/productdetails.aspx/pedge_m600?c=us&... , точнее, оно похоже по спецификациям, но процессора там не 2, а 4. Точно модель сказать не могу.

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

В этот раз вы ошиблись, ибо таки int32 - 4 байта.

Спасибо за ссылку Лоровскую.

Т.е. вы таки за? Или - таки ещё воздерживаетесь?

> Проблема в том, что ни я, ни команда не можем понять точку зрения начальства, ибо оно никак не обосновывает, кроме слов - "делайте так" или "что? не в состоянии разобраться в мультипроцессности?"

Ну против лома...

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

Ну так напиши: "использование OpenMP позволило ускорить обработку в N раз", "поскольку все обрабатываемые даные хранятся в разделяемой памяти, многопроцессная модель не дает никакого выигрыша по сравнению с многопоточной" (насколько я понимаю, вам именно так придется делать).

> В этот раз вы ошиблись, ибо таки int32 - 4 байта.

Читал невнимательно.

> Т.е. вы таки за?

Я давно за %) В данном случае устойчивость к сбоям (единственное преимущество мультипроцессности) не имеет значения, а всё остальное мультипроцессность усложняет.

> это дешего [grammar-nazi mode] дёшево

>> Т.е. вы таки за?

>Я давно за %) В данном случае устойчивость к сбоям (единственное преимущество мультипроцессности) не имеет значения, а всё остальное мультипроцессность усложняет.

+1. Тем более что программисты имеют свое мнение. Им же делать. А начальству просто показать полуфабрикат загружающий все процессоры, достаточно им будет.

Распараллеливание на уровне внешнего цикла более эффективно, чем внутри, т.к. потокам нужно реже взаимодействовать. Создавать новый поток ради умножения двух int32 - это точно маразм, т.к. умножить два числа во много-много раз быстрее, чем "просто" создать поток.

К слову, я слышал, что некоторые (широко известные в малограмотных кругах) операционные системы при этом показывают почти нулевую загрузку CPU (наверное, из-за того, что время запуска потока не считают как занятое время). Может, у вас загрузка CPU 20% по той же причине? Просто мне не очень верится, что "несколько различных мат. операций" занимают бОльшую (80%) часть времени.

Если у вас всего 4 ядра, то лучше сразу поделить всю задачу на 4 части и спокойно (без MP) обрабатывать каждую часть на одном ядре. Если ваша задача это позволяет, то это лучшее решение.

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

> затребована письменная документация с обоснованием

Ну и подготовили бы... всей командой. В рабочее время.

> "делайте так" или "что? не в состоянии разобраться в мультипроцессности?"

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

А если ещё более по существу - плохо, что начальство не знает, что у вас УЖЕ есть распараллеленность через openMP. Надо начинать именно с этого. Вот у вас 4 ядра. Во сколько раз ускорилось приложение при переходе на openMP? В 4? Значит мультипроцессностью УЖЕ полностью сделана, просто вы не удосужились об этом рассказать. Процентов на 20? Значит вы не к месту применили openMP (слишком низко) - сделайте распараллеливание тем способом, какой вам удобен (неважно, процессы, потоки или openMP - это ВСЁ "мультипроцессность" в терминах вашего босса) - но не на нижнем уровне, а на верхнем, т.е. разложите на отдельные задачи внешний цикл, а не тратьте всё время на порождение потоков.

расставь переносы. читал - глаза сломал.

// wbr

В зависимости от архитектуры и способа реализации ПО возможно использовать и распараллеливание процессов и многопоточность и, в случае необходимости, даже селектирование.. Необходимо, как бы, выделить основные задачи и вспомогательные.. Для выполнения основных задач можно использовать распараллеливание процессов, а для вспомогательных, в том числе и в рамках различных процессов, использовать многопоточность.. В общем случае, всё это сильно зависит от способов реализации..

Отлично) Спасибо огромное.

Вы не совсем правильно поняли. То, что я писал - про a*b + b*c - это было для примера, чтобы не запутывать людей из - за собственной неграмотности в терминологии.

На самом деле - распараллеливаемые операции - несколько более сложные (т.е. a*b и b*c - это одномерная свёртка одной строки матрицы (до 1е4 элементов) с одномерным ядром фильтра, решили их параллелить, тк операции в меру длительные и абсолютно не зависят друг от друга, но должны длиться примерно одинаковое количество времени, поэтому и проблем с синхронизацией не будет).

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

Та. Всей командой. Мои и так пашут ,как кони, ибо не хочется опоздать по срокам. Поэтому, рабочее время отпадает, а дома работать - мне совесть не позволит их об этом просить, тк и так на полную выкладываются.

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

В любом случае - обязательно дам прочитать эту тему подчинённым. Да и спасибо вам.

Кстати, ещё вопрос уважаемым знатокам, какая из библиотек многопоточности является рекоммендованной. Может кто - нибудь тчо - нибудь пробовал на личном опыте? OpenMP, pthread, mpi или что - нибудь ещё, о чём мне, как неспециалисту, неизвестно?

Даже на данный момент - спасибо всем отписавшимся. Вы мне оказали просто неоценимую помощь.

> какая из библиотек многопоточности является рекоммендованной. Может кто - нибудь тчо - нибудь пробовал на личном опыте? OpenMP, pthread, mpi

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

Тут вообще тусовалось два-три специалиста по кластерам и параллельным вычислениям, но один ушел, а остальные и раньше редко появлялись. Может, на parallel.ru знают больше.

> На самом деле - распараллеливаемые операции - несколько более сложные (т.е. a*b и b*c - это одномерная свёртка одной строки матрицы (до 1е4 элементов) с одномерным ядром фильтра, решили их параллелить, тк операции в меру длительные и абсолютно не зависят друг от друга, но должны длиться примерно одинаковое количество времени, поэтому и проблем с синхронизацией не будет).

Как вам сказали ранее лучше распредлять по процессорам на самом высоком уровне из возможных(в разумных пределах разумеется). Например разбить матрицу на ~16 блоков(не меньше числа ядер, можно больше если требуется дальнейшая балансировка нагрузки) и раздать их нитям. Вызывать OpenMP (хорошо хоть что нити там не каждый раз создаются =) ) для ~1000-10000 операций с интами точно не стоит, синхронизация будет больше времени занимать (может поэтому у вас загрузка процов такая низкая?).

> Кстати, ещё вопрос уважаемым знатокам, какая из библиотек многопоточности является рекоммендованной. Может кто - нибудь тчо - нибудь пробовал на личном опыте? OpenMP, pthread, mpi или что - нибудь ещё, о чём мне, как неспециалисту, неизвестно?

Пробовал все вышеозначенные + Intel Threading Building Blocks. MPI - это не нити, а именно процессы. Возможно вам имеет смысл на него посмотреть как на самый удобный для такого рода задач метод использования кластеров. Удобен наличием т.н. коллективных операций - собрать данные со всех процессов, разослать, массово обменяться и т.д. Ничего особо сложного, хотя затрат времени требует. Pthread - низкий уровень нитей, из разряда "я порождаю нить, вот ее main", сделать можно что угодно, но геморойно. OpenMP - компиляторный метод использования нитей, удобен для т.н. Data Parallel алгоритмов(много данных, мало зависимостей, почти одинаковые действия и т.д.), остальное тоже можно, но не так удобно. TBB - библиотечный метод использования нитей, нити там убраны поглубже(переносимость). Основная концепция - Task Parallelism. Основное приемущество перед OpenMP - более четкое разделение задач(требуется выделять классы, лапша из форов не пройдет), и относительно нормальная(какая тут возможна) поддержка отладки поскольку все прописано в терминах языка а не в виде надстройки над ним.

А теперь о главном, нити vs процессы. У процессов(для них я бы рекомендовал MPI) есть одно imho важное в вашем случае приемущество - можно задействовать кластера. Если у вас задача считается 4 секунды, а нужно 0.1 - нити на данный момент вам врядли помогут(32 ядра в одном корпусе конечно бывает, но это редкость, да и расчитывать на абсолютную мсаштабируемость не приходится). К тому-же у интелов весьма плохая масштабируемость работы с памятью(усиленно ждем массовый серверный нехалем). Если данные мало переиспользуются (например умножаем матрицу в 2Гб на вектор - переиспользование практически отсутствует) - на 8 ядрах наиболее вероятное ускорение ~2.5-3 при условии полной загрузки всех ядер, пофигу нити/mpi. У амд с этим получше - но тоже на 8 расчитывать не приходится. Это я к чему - оцените, получится ли у вас уложиться в нужное время с использованием одного узла или нет, если нет - mpi практически без вариантов.

Ого. YesSSS, потрясающий обзор. Спасибо. Я внемлил и знаю, что в понедельник отдам своим на перерассмотрение, дабы оценить, что же нам всё - таки лучше.

У меня только один вопрос - вы написали, что для ~1000 - 10000 операций с интами даже не стоит и думать о вызове OpenMP, проблема в том, что свёртка ~10000 элементов вектора с некоторым одномерным ядром - это не 1е4 операций, а не менее 1е5 и вплоть до 5е5 операций в зависмости от ядра свёртки. В таком случае стоит уже задействовать OpenMP или всё же лучшу убрать его из этой части проекта, тк на синхронизацию затратится больше времени?

И ещё вопрос к вам. Может, вы посоветуете литературу по данному вопросу (параллелизму и его теории) на языках [немецкий, русский, украинский, английский] или ничего толкового нет и всё надо испытать на себе?

tailgunner, спасибо ещё раз)

Простите за оверквотинг, но ещё один вопрос, если таки выяснится, что мы сможем уложиться в нужное время с использованием одного узла, то каковы будут ваши рекоммендации? Я так понимаю, что в этом случае выбор между нитями и потоками уже не так очевиден?

Советую изучить контент данного ресурса - http://parallel.ru/

Спасибо. Я уже часов 7 изучаю. Случайно натолкнулся. Просто, хотелось получить мнения "бывалых" и рекомендуемую литературу от них, т.к. литературы достаточно много и несколько десятков книг я никак не смогу осилить в разумные сроки ::--((

> этом случае выбор между нитями и потоками уже не так очевиден?

Нить и поток - одно и то же :) А в данном случае нет выбора между нитями и процессами - только процессы и MPI (хотя можно навернуть что-нибудь самодельное). По крайней мере, ИМХО.

Это понятно.. Вообще, это довольно сложная тема, требующая соответствующего внимания и затрат.. Дело в том, что не существует универсального решения. А информации, приведённой тобой, явно не хватает для того, чтобы сложилось более-менее вразумительное понятие о постановке техзадания. В любом случае, советую рассматривать возможные решения в совокупности, а не в раздельности. И, также, прислушайся к тому, что излагал YesSSS.

Блин. Начинаю заговариваться. Я и имел в виду процессы и нити. Боюсь. что мне будут сниться вскоре уже процессы с нитями.

Ну. К YesSSS я не просто прислушался. Я внял, принял и осознал.

Какая именно информация требуется? Выложу всё, как на духу.

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