anatolikostis у буля есть несколько системных дыр, которые надо затыкать компилятором или руками. О них даже говорили сами АМД-шники.
в первую очередь это касается распараллеливания и операций с плавающей точкой. Есть, так-же дыры, которые заложены в идеологию
Тут дело вот в чем.
1 модуль бульдозера состоит из двух независимых блоков для работы с целыми числами и одного широкого (256 бит) блока, который предназначен для работы с плавающей точкой и который может делиться на 2 части, если идет вычисление сразу с двух полуядер
см. рисунок
https://www.***************/images/news/2009/11/12/bulldozer_01.gif
и вот таких модулей - ровно 4 штуки. Обмениваются они (модули) друг с другом через кэш третьего уровня (который не быстр) или через память, которая еще медленнее. Однако при выполнении одной распараллелиной задачи относимой к одной программе, полуядра могут общаться через общий l2. Это самая оптимальная ситуация, для двухпоточных программ
например
Программа выполняет 2 процесса, которые попадают на ядро А1 и А2, тогда эти полуядра молотят данные из общего кэша второго уровня. если-же планировщик кидает процесс на ядра А1 и В1 то обмен данными уже идет через Л3 и всё это начинает тормозить. Т.е. Планировщик должен разбирать какая программа выполняется и закидывать её на соседние "полуядра". Помимо всего
Еще одна проблема, которая пока не сильно заметна, но которая проявится на бульдозерах в будущем.
Исполнение широких AVX (256 бит) возможно только на общем фпу -> если avx исполняется на ядре А1 ядро А2 начинает тротлить, потому что свободные мощности заняты.
еще одна проблема бульдозера
очень узкий декодер. Декодер может производить до 4х моп-ов за так, однако этого для 2х полуядер может-быть недостаточно. Мало того. система предсказания ветвлений у бульдозера Очень сильно улучшилось по сравнению с к10 (у них это вообще головная боль была). и система декодирования может банально не успевать генерить моп-ы для исполнительных юнитов.
Полагаю, что подобный фокус провернут из-за того, что декодер должен работать на частоте большей, чем частота процессора, а буль рассчитывается на высокие частоты, судя по его микроархитектуре.
еще одна проблема
сами по себе ядра бульдозера (по сравнению с к10) урезаны на один ALU и на один AGU. это связано с тем, что декодер стал уже и не способен "кормить" мопами вычислительные блоки.
Итак. кратко резюмирую.
1 какая должна выглядеть программа, идеально работающая на бульдозере.
Программа должна быть распараллелена на 8 потоков. У неё должны отсутствовать инструкции AVX исполняемые одновременно. В идеале надо почитать оптимизационный мануал. и использовать такие инструкции, которые преобразуются в 1-2 моп-а (или больше, но тогда ядра должны быть загружены работой, пока инструкция декодируется [например FMULL 64 может выполняться до 36 тактов машинного времени]), тогда все полуядра будут загружены и бульдозер полностью продемонстрирует свой потенциал
2. что ждать от амд
а. В ближайшее время выйдет драйвер процессора, который оптимизирует раскидывание процессов по ядрам (на многозадачке, думаю, %10 производительности это прибавит) Помимо всего прочего этот-же меджик драйвер должен научиться загружать ядра однопоточными приложениями по принципу 1модуль 1 программа, тогда весь широкий fpu блок будет в распоряжении 1 программы. и это еще даст неплохой процент при условии, что декодер справится с такой работой.
б. в перспективе.
Расширение декодера (реально бутылочное горлышко) Но надо учитывать, что декодер, по идее, это самое сильно нагруженное место в процессоре и он не хило так греется. А более широкий декодер будет греться еще сильнее.
добавление 1-2 ALU и AGU, что позволит сравняться с ipc на 1 полуядро с К10 (+1) Nehalem (+2)
но это произойдет только в том случае, если в АМД поймут, что высоких частот выжать с нового процессора не получится. Или мы увидим процессор, который в штатной частоте будет брать 4.5 ггц (такое, кстати, тоже возможно)
, так что посмотрим как будет
