Средства и методы разработки

Многоядерность: похмелье будет жестким. Итак, в последнее время все просто с цепи сорвались. Куда не плюнь, кругом одни анонсы - "у нас ХХХ ядерный чип с производительностью YYY GFLOPS. Всех порвем!" Времени разбираться детально со всем этим нет, но некоторое количество статей просмотрел, и подсознание выдало некоторые интересные результаты. :) Пусть у нас есть массив из 100 чисел, и нам невтерпеж узнать сумму всех этих чисел.for (i=0;i<100;i++) {sum += array(i);} // ненужные подробности опущены В процессе исполнения этого особогениального кода второе, как и все остальные ядра, будут курить бамбук полной грудью. Для двухядерного проца то же самое должно быть:for (i=0;i<50;i++) {sum1 += array(i);} for (i=50;i<100;i++) {sum2 += array(i);} sum = sum1 + sum2;Для приведенного выше цикла компилер (теоретически) может выполнить такую оптимизацию, но поскольку в реальности цикл может быть далеко не так прост, то едва ли стоит расчитыват на это. Вы представили себе читабельность кода для 8 ядерного процессора? Вам полегчало? Понятно, что ручками такую оптимизацию не выполнить. Аминь. Либо делать хитрозадый кодогенартор для С, либо делать специальные классы для С++ (а в идеале в комплекте с хорошим шаблоном). Как ни крути, а сложность реализации (количество кода) даже самых простых примитивов будет просто аццкой. С суммированием по частям и каким-нибудь БПФ еще как нибудь справимся, а как насчет многоядерной сортировки? Поиска по деревьям? Понятно, что без метапрограммирования с мощной IDE все это будет игрушкой. Нужно выделять параллельные куски кода, графически их отображать и пр. В общем, система тегов по взрослому. Plain text для работы тут точно не прокатит. Вы уже прикинули, сколько будет стоить программист, который умеет так программировать? :) Ну а сложность тестирования, вероятно, ваще будет расти экспоненциально в зависимости от количества ядер. :) Вся засада приведенных выше примеров в том, что задача разбита на малые блоки, жестко синхронизированные между собой. Пойдем другим путем. Преположим, нам на обработку поступает большой блок данных - картинка. И мы жмем ее в JPEG. На первый взгляд, все кульно - разбили на блоки 8Х8, и натраивли кучу процессоров на обработку своего кусочка данных. DCT, квантователь - все ок. Так то оно так, но задача формирование выходного потока трудновато распареллеливается. Во первых, ей на вход желательно подавать данные от обработки каждого блока строго в определенном порядке, во вторых, сам хаффмановский сжиматель распараллелить - та еще задача. В итоге имеем некий естественный порог скорости, который наращиванием ядер не преодолеть. Как результат, получем: * полное переучивание программеров * переход на метапрограммирование, само владение которым подразумвает аццкий уровень интеллекта. Теперь еще одна засада. Из того, что в пЫсюке стоит N ядер, значит, что для нашей задачи мы получим M ядер, причем M<=N. Т.е. мы должны иметь предкомпилированные варианты на 2, 3, 4 и пр. ядра. Ибо при попытке динамической перестройки апликухи мы точно просрем одноядерному решению. Вы уже представили себе дистрибутив Office 2010 на пачке HD DVD дисков? В варианте сервера, или нагруженной рабочей станции, все несколько проще. Там по определению много потоков и процессор, и разложить все это по ядрам - линейная задача ОСи. Т.е. выжать максимальную суммарную производительность четырехядерного проца на 4 независимых копиях Word гораздо проще, чем на задаче MPEG* кодирования. Между тем, для практического использования многоядерность есть благо. Одно яро на ОСьку, другое на IO, остальные пусть юзеровщиной занимаются. Вот только симметричность тут не нужна. ОСевому ядру криптография нужна, IO плавучка нафиг не уперлась и т.д. Простое наращивание кучи ядер ничего не даст. Нужно много простых ядер и ортогональная шинная матрица между ядрами и специальными исполнительными блоками - FPU, криптография, IO и пр. Система аллокирования ресурсрв - вот эта плавучка на это ядро, вот эта криптография - на это. А это уже недеццкая задача. Резюме: 1. Многоядерность потребует специального обучения программеров. 2. В "чистом виде" она будет доступна только для высоко бюджетных проектов, для остальных - только в виде либ от "толстых". Еще одна заивисмость от толстых. 3. Есть масса задач, где полную производительность многоядерного проца не выжать даже теоретически. 4. Производительность кристалла как сумма производительности ядер - маркетинговая херня, столь же важная на практике, как сумма всех скоростей всех портов Ethernet коммутатора :)