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

S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания.
Тут есть ещё такой момент. Описанный, ЕМНИП, у Кнута.
Возьмём какую-нибудь простую задачку. Например, сортировку массива.
Есть десятки алгоритмов, построенных для однопоточных реализаций. Есть несколько алгоритмов, которые построены для многопоточных.
Возьмём экстремальный пример: предположим, у нас есть неограниченное количество "ядер" — вычислителей, каждый из которых может выполнять простую операцию типа compare-and-swap за одну стадию.
Длина массива — N. За какое минимальное количество стадий мы можем отсортировать массив?
Внезапно выясняется, что у современной математики нет способа решения таких задач. Для небольших количеств ядер (<10) нам известны оптимальные конфигурации процессорной сети — полученные, собственно, прямым перебором. Уже при K=50 мы не можем нарисовать эффективную сеть.

Этот простой пример показывает причины, по которым твоё предположение пока что весьма сомнительно. Известные нам алгоритмы параллелизации задач начинают сосать при выходе количества ядер за пределы нескольких десятков.
Вот хороший анализ: http://lira.imamod.ru/FondProgramm/Sort/ParallelSort.pdf
Посмотри на алгоритм Бэтчера. Видно, что при 512 ядрах мы сумели разогнать сортировку с 83 секунд до 1.29. Круто? Круто.
Но добавление ещё 128 ядер даёт нам всего лишь 0.08 секунды ускорения. Если у нас бюджет на эту сортировку — 100мс, то мы, судя по форме графика, всё ещё ой как далеки. А слоты под процессоры уже закончились.
Именно поэтому современные тенденции — в консолидации. Мы запихиваем по 48 ядер в одну коробку не для того, чтобы отдавать странички в 48 раз быстрее, а чтобы обрабатывать в 48 раз больше параллельных реквестов, тратя всего лишь в 5 раз больше на электричество и охлаждение.