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

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

PD>Как-то все думал, стоит ли говорить то, что скажу. Нестандартно это очень...

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

Именно так и есть!


>>Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потокамию. И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

PD>А зададимся-ка таким вопросом. Представьте себе. что через 5 лет будет выпущен одноядерный процессор с быстродействием в 80 раз больше нынешнего. Вы его предпочтете или это многоядерное чудовище ?

К сожалению, мы перед таким выбором не стоим...



PD>Как видите, хоть и незначительное, но все же большинство предпочитает одноядерный процессор паре двухядерных с той же суммарной частотой. И это неудивительно — про распараллеливание много сказано, а попробуйте обратную задачу решить — заставить один поток исполняться на двух процессорах, дабы полностью использовать мощность компьютера. Именно так — на остальные процессы наплевать, им ничего не дадим (насколько сможем), а вот этому процессу — всю мощь PC. А он однопоточный по характеру самого алгоритма. Ну и как ?

Так же как и алгоритму, который упирается в пропускную способность памяти, или в пропускную способность сети. Они все не будут использовать процессор на полную мощность.



PD>Иными словами, не сумев решить задачу повышения быстродействия одного ядра, разработчики процессоров пошли по экстенсивному пути, начав наращивать число ядер. Возникающие проблемы при этом перекладываются на программистов, пусть они решают.

Так и есть.

PD>Я уж не говорю о том. что при этом применяются решения, которые совсем не очевидны. Тут много о кэше памяти говорилось. А ведь кэш-память — это кэш ОП, а не процессора. И быть ей надо бы ИМХО именно кэш-памятью на самой ОП, а не у каждого процессора, тогда бы и проблем с синхронизацией кэша не было бы. Если процессор == поток, то получаем кэш у потока, вместо того, чтобы иметь его у процесса, отсюда и все проблемы. Но сделать иначе — технически невозможно, а точнее, не заложено в архитектуру.


кэш-памятью на самой ОП — бессмысленно. ОП — и есть свой кэш.



PD>Жить нам, конечно, с этими многоядерными монстрами придется, и проблемы решать — тоже. Но, похоже, многие из них не фундаментальные проблемы, а проблемы, которые на нас изготовители оборудования переложили.

Так же как и IOCP, интерфейс которого переложили на нас изготовители ОС. Так же как и MMX/SSE/SSE2/SSE3/SSE4, которое на нас переложили изготовители процессора. И т.д. и т.п.


PD>P.S. Лично мое мнение о многопоточности очень простое. Если по характеру алгоритма распараллеливания нет — не надо ее насильно туда совать. Если оно может быть, но можно обойтись без него — тоже лучше не надо. Вот только если обойтись нельзя, то есть алгоритм по своей сути параллельный — тогда да.

Например, всё серверное ПО замечательно распараллеливается — на уровне транзацкий сам бог велел распараллеливать.
Что такое "по своей сути" — сложно сказать...