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

R>Меня в этом вопросе интересовала реализация этого дела и организация ран-тайм системы поддержки. Поэтому со своей стороны могу дать ссылки, касающиеся именно реализации:
R>Lazy Threads: Compiler and Runtime Structures for Fine-Grained Parallel Programming:
R>http://www.eecs.berkeley.edu/Pubs/TechRpts/1997/CSD-97-975.pdf

R>Cilk: An Efficient Multithreaded Runtime System:
R>http://supertech.csail.mit.edu/papers/cilkjpdc96.pdf

Спасибо за ссылки!

R>"Псевдо-автоматическое распараллеливание" возможно, когда пользователь явно указывает в программе "потенциальный" параллелизм, а компилятор/ран-тайм заставляют его реально выполняться параллельно. К этому типу относятся все эти lazy-вычисления, futures, активные объекты и т.д. Но фактически тут вся работа остаётся на программисте. У компилятора тут маленькая задача. У компилятора тут, как ни странно, задача даже больше не "сделать" параллелизм, а "подавить" параллелизм.

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

R>Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".

Я вот ещё, что имел ввиду, затронув тему автоматизации распараллеливания, в свете будущих перспектив промышленного программирования для работы с многопроцессорными (многоядерными) системами.
Существуют прогнозы, что в ближайшее время (5, 10 лет) нас ожидает скачкообразный рост количества ядер на одном процессоре, вплоть до нескольких сотен ядер где-нибудь к 2015 году. Собственно, например архитектуру Cell или GPGPU можно рассматривать как первую ласточку. А несколько десятков ядер уже есть даже в Roadmap-ах производителей.

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

В этой связи языки и технологии, вроде Haskell, Lisp с параллельным исполнением и т.п., которые сейчас слишком расточительно расходуют ресурсы, могут оказаться востребованными. Если код на них работает, допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо медленно, особенно в вычислительных задачах, но если они позволят программисту быстро написать параллельно исполняющуюся программу на 1600 ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной программы.

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