Здравствуйте, remark, Вы писали:
Как-то все думал, стоит ли говорить то, что скажу. Нестандартно это очень...
А не кажется ли вам, господа, что многопоточность (а точнее, многоядерность) — не от хорошей жизни. Иными словами, это перекладывание проблем с аппаратуры на программистов ?
>Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потокамию. И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)
А зададимся-ка таким вопросом. Представьте себе. что через 5 лет будет выпущен
одноядерный процессор с быстродействием в 80 раз больше нынешнего. Вы его предпочтете или это многоядерное чудовище ?
Я в свое время голосование устроил
http://www.rsdn.ru/poll/1851.aspxАвтор: Pavel Dvorkin
Дата: 25.06.07
Вопрос: Какую машину бы Вы предпочли
Как видите, хоть и незначительное, но все же большинство предпочитает одноядерный процессор паре двухядерных с той же суммарной частотой. И это неудивительно — про распараллеливание много сказано, а попробуйте обратную задачу решить — заставить один поток исполняться на двух процессорах, дабы полностью использовать мощность компьютера. Именно так — на остальные процессы наплевать, им ничего не дадим (насколько сможем), а вот этому процессу — всю мощь PC. А он однопоточный
по характеру самого алгоритма. Ну и как ?
Если же ситуация иная, и потоков много, то на этом жутком 80x скоростном процессоре время переключения потоков будет настолько ничтожным по сравнению с суммарным временем, что им просто можно будет пренебречь (разумеется, в предположении, что и скорость работы памяти увеличится так же) . И можете теперь рассматривать как один 80x скоростной процессор или , если хотите, как 80 1x-скоростных процессоров или как-то еще иначе.
Иными словами, не сумев решить задачу повышения быстродействия одного ядра, разработчики процессоров пошли по экстенсивному пути, начав наращивать число ядер. Возникающие проблемы при этом перекладываются на программистов, пусть они решают.
Я уж не говорю о том. что при этом применяются решения, которые совсем не очевидны. Тут много о кэше памяти говорилось. А ведь кэш-память — это кэш ОП, а не процессора. И быть ей надо бы ИМХО именно кэш-памятью на самой ОП, а не у каждого процессора, тогда бы и проблем с синхронизацией кэша не было бы. Если процессор == поток, то получаем кэш у потока, вместо того, чтобы иметь его у процесса, отсюда и все проблемы. Но сделать иначе — технически невозможно, а точнее, не заложено в архитектуру.
Вот такие пироги...
Жить нам, конечно, с этими многоядерными монстрами придется, и проблемы решать — тоже. Но, похоже, многие из них не
фундаментальные проблемы, а проблемы, которые на нас изготовители оборудования переложили.
P.S. Лично мое мнение о многопоточности очень простое. Если по характеру алгоритма распараллеливания нет — не надо ее насильно туда совать. Если оно может быть, но можно обойтись без него — тоже лучше не надо. Вот только если обойтись нельзя, то есть алгоритм по своей сути параллельный — тогда да.
