Названы преимущества в производительности чипов Kaveri над Richland [Версия для КПК]

OSZone News

25-11-2013, 10:30

http://www.oszone.net/figs/pics/hardlgs-Scorpion81-1099274995502cbd5b463f7.jpg (http://www.oszone.net/22684/Kaveri_versus_Richland)Hardware (http://www.oszone.net/4480/News_Hardware) » Названы преимущества в производительности чипов Kaveri над Richland (http://www.oszone.net/22684/Kaveri_versus_Richland)
Ранее в этом месяце компания AMD в рамках AMD Developer Summit 2013 сообщила подробную информацию о намеченных на будущий год ускоренных процессорных элементах Kaveri и их технических характеристиках. Теперь доступны новые подробности относительно работающих на ядрах SteamrollerB и графической архитектуре GCN чипах. APU Kaveri б... (http://www.oszone.net/22684/Kaveri_versus_Richland)

Читать дальше на OSZone.net: "Названы преимущества в производительности чипов Kaveri над Richland" (http://www.oszone.net/22684/Kaveri_versus_Richland)

AMDBulldozer

25-11-2013, 13:53

Жаль, что AMD не сообщила о том при каких именно условиях наблюдается рост производительности до 20%. Точнее, интересно было бы узнать, насколько выросла производительность в однопоточных приложениях.
Первоначально ожидался рост на 30-35% при исполнении второго потока команд на том же модуле за счет добавления второго декодера команд и не более 5-10% роста производительности потока за счет остальных улучшений.
Под "остальными улучшениями" я понимаю:
- увеличение кэша команд первого уровня. За счет низкой аcсоциативности этого кэша, 2 против 8 у процессоров Intel, эффективность его работы заметно меньше по причине значительного количества кэш-промахов. Сама AMD ожидает 30 процентов (не путать с процентными пунктами) роста кэш-попаданий;
- повышение точности работы блока предсказаний переходов (слишком объемная тема, чтобы в неё углубляться);
- увеличение объема очереди декодированных команд;
- увеличение объема регистрового файла (вполне естественное решение с учетом предыдущего пункта);
и т.д.
Как легко видеть, все действия, кроме самого первого, являются чисто косметическими доработками. Точно также легко понять, что все они в большей степени повлияют на рост IPC при исполнении двух потоков команд на одном модуле.
Действительно, когда модуль исполняет только один поток команд, этот поток получает все 64кБ кэш-памяти команд первого уровня, что сразу уменьшает процент кэш-промахов. Увеличение размера очереди команд необходимо для того, чтобы уменьшить периоды простоя исполнительных устройств - ведь в длинной очереди с большей вероятностью каждый такт найдется команда для исполнения у которой уже готовы исходные данные. А чем длиннее очередь команд, тем больше регистров потребуется для переименования...

AMD сделала важный шаг на пути к превращению модуля в два ядра (хотя надо будет еще посмотреть, насколько эти декодеры окажутся реально независимы друг от друга. Мне трудно себе представить, что модуль может иметь два полноценных декодера и декодировать до 8 команд за такт). Правда, пока только один из четырех. К сожалению, на данный момент непонятно, сможет ли компания добиться заметного роста производительности одиночного потока команд. Если нет, то, увы, новая архитектура ей вряд ли сильно поможет.