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

Мой недавний анализ этой темы пришел почти к тем же выводам.

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

2. Алгоритм для одного исполнителя нельзя автоматически исполнить многими. Одного контрпримера достаточно (типа сортировки)

R>Всё это я называю «многопоточность на одном ядре». Фактически система, построенная по таким принципам, образно является «однопоточной с кооперативной многозадачностью».

3. Параллельность делится вообще на две вещи — многопоточность и многоядерность. Многопоточность это когда в вашей программе должны работать паралелльные процессы просто по природе задачи (например, GUI работает дальше, а поток в фоне заливает файл). Многоядерность это когда вы хотите получить прирост до N раз при наличии N ядер (исполнителей). Вещи между собой вообще-то никак не связанные, кроме того единственного общего момента, что N ядер могут заняться одновременно вашими N (или 2N) потоками. Многопоточность это вообще не проблема, реализуется даже в рамках одного алгоритма с одним исполнителем, а при поддержке языка даже наличие потоков в ОС не особо имеет значение. Сегодняшняя проблема параллельности — в многоядерности.

4. Multithreading с общими данными (синхронизацией) — отстой. Языковая поддержка типа atomic {} не решает проблемы. Каждый наверное уже обжегся. Многие уже самостоятельно дошли до вывода, что чем меньше разделяемых данных — тем меньше багов. Синхронизации не дожно быть.

5. По причине п.1 и п.2 автоматическая многоядерность пока что мечта. Даже если изобретут другую науку об алгоритмах, создающую автоматически параллелящиеся алгоритмы, все равно нельзя просто взять всю массу накопленного софта и переписать.

6. Вывод: современное решение должно обязательно работать с классическими алгоритмами, но требовать от программиста делить систему так, чтобы наибольшее число ядер могли быть задействованы над исполнением независимых последовательных алгоритмов.

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

R>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.
R>К сожалению пока никто не придумал как приготовить этот рецепт в общем виде... Т.е. что бы программист был занят только прикладными задачами, а всё остальное происходило как-то само собой.

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

Может такая архитектура, даже реализованная на уровне ОС (Singularity вспомнил ) и не загрузит 1000 ядер, но для нашего ближайшего будущего — 1-30 ядер — работает просто превосходно.