English | 中文 | Русский | Français
342 Тем для обсуждения
3,590 Открытых обсуждений
- Association for Computing Machinery TechNews (ACM)
- Go Parallel! (Dr. Dobbs)
- HPCwire (Tabor Communications, Inc.)
- insideHPC (John West)
- Joe Duffy's Weblog (Microsoft)
- Microsoft Parallel Programming Development Center (Microsoft Germany)
- MultiCoreInfo.com
- scalability.org (Scalable Informatics)
- Software Dev Blog (Intel Germany)
- Soft Talk Blog (Intel United Kingdom)
- The Moth (Microsoft)
Intel® Architecture Code Analyzer for Intel® AVX Instruction Set
Maxym Dmytrychenko (Intel) (10 пост(а)) 14.04.2009 12:47
Мы движемся и движемся вперед. Как известно, в новых процессорах, набор SSE инструкции не планируеться расширять, улучшать и так далее, хотя само направление живое и переродиться под несколько другим именем - Advanced Vector Extensions или в сокращении - AVX.
Одно из главных и принципиальных изменений это изменения базовых типов, с которыми работают инструкции, а вернее их расширения до 256 бит вместо 128 т.е в два раза.
Другими словами - с SSE одновременно можно проводить операции с четырьмя переменными типа float, а с AVX - c восемью.
Уже доступны компиляторы, эмуляторы, но не само железо, харт - его стоит ожидать познее в следующем году или типа того 
Доступны так же первые тулзы которые должны помочь в процессе разработки и сообственно дальнейшей оптимизации продукта.
Как, я думаю, все уже слышали о whatif.intel.com - сайт который хостит многие открытые разработки/наработки и "как бы" продукты.
Почему "как бы" - в силу того что это процесс исследования необъятной предметной области, исследования ведеться и в открытом режиме, где Ваши комментарии очень даже приветствуються!
Так вот - 1 Апреля (причем не шутка как проект так и его анонс) вышел в свет так называемый Intel® Architecture Code Analyzer for AVX Instruction set (IACA)
Который стараеться на основе использования AVX инструкций показать общую картину использования Портов процессора, вместе с вопросами тайминга как Latency/Throughput.
Cтоит немного объяснить что подразумеваеться под понятием "порты процессора":
- Внутри процессора есть различные модули, которые являються элементами общего конвейэра (pipeline) обработки инструкций.
- Один из таких модулей - Execution Core (исполнительный модуль как следует из названия ) содержит в себе дальнейшее разделение на так называемые Порты и Исполнительные Юниты (Execution Units)
Вот именно эти самые Порты (пронумерованы от 0 до 5 ) и являються воротам к исполнению команд в последующих Execution Unit(s). Здесь стоит сказать что они (Execution Unit) не универсальны сами по себе и могут выполнять только предопределенного типа работу.
Так, например операции над типом Integer в SSE инструкциях подготавливаться для дальнейшего исполнения
ТОЛЬКО внутри Порта 0 или 5 , а вот неSIMD Integer - могут на 0,1,5 . Сохранение данные - только Порт 4 , а вот чтение - только Порт 2.
Как видно - довольно много зависимостей и ограничений , которые между прочим еще и варьируються от одного поколение процессоров к другому.
(Достаточно обширно данная тема описана в Intel Manuals и в частности Intel® 64 and IA-32 Architectures Optimization Reference Manual)
В силу того что инструкции следуют последовательно, то вполне вероятно что некоторые последовательности будут загружать определенные Порты, возможно даже не оптимально, тем самым замедлять всю имплементацию алгоритма
(я намеренно опускаю здесь вариант Out-Of-Order исполнения )
Теперь должна быть понятна цель IACA - показать и попытаеться оценить все эти зависимости, если они есть.
Само по себе использование IACA довольно простое, например так:
#include "iacaMarks.h"
...
for (j=0; j<N; j++){
IACA_START
a[j] = b[j]+scalar*c[j];
IACA_END
}
Oчень советую посмотреть IACA User Guide и в частности Раздел 5 - Analysis and Optimization Example для примеров возможной оптимизации.
ну и на последок, главная ссылка - http://software.intel.com/en-us/articles/intel-architecture-code-analyzer/
PS Где взять AVX компилятор и эмулятор ? - читайте Frequently Asked Questions по линку выше...
Категории: Intel Software Network, Открытый код, Разработка софта
Комментарии (9)
| 14.04.2009 21:25
ksili
|
Сложно конечно спорить с представителем Интела :-) но я попробую добавить пару замечаний... По-моему понятие портов здесь объяснено несколько неправильно. Поясню на примере архитектуры P-4. В любом процессоре есть несколько исполнительных устройств (EU). Каждое из них имеет по сути свой конвейер, к-рый конечно является частью общего конвейера. Попав в одно из EU, инструкция далее выполняется уже его конвейере, не попадая в конвейеры других EU. Только уже по выходе из него выполняются кое-какие проверки и запись результата в кэш. Так вот порты не занимаются работой по выполнению инструкций. Этим занимаются EU. А порты являются воротами к этим устройствам. Т.е. в препроцессоре инструкции анализируются и попадают в очереди - каждая к своему EU. А попадают в них они как раз через порты. Поэтому они, кстати, более полно называются портами диспетчеризации. Таким образом, об эффективности использования процессора, конечно можно (и нужно) судить по загруженности портов. Но сами порты инструкции НЕ ВЫПОЛНЯЮТ, как было написано выше. В некоторой мере можно даже поставить знак равенства между загруженностью порта и загруженностью соответствующего конвейера. Может быть в новых процессорах уже всё по-другому? Тогда расскажите в чём я был неправ. Хотя, мне кажется, в любом случае из названия "порт" уже ясно, что это что-то, что пропускает инструкции из одного места в другое, а не выполняет их... |
| 15.04.2009 03:01
Maxym Dmytrychenko (Intel)
|
Первым делом - в последних процессорах Execution Core несколько изменен со времен P4. Полное название Портов - Issue Port(s). В тот момент, когда Front End размолотил инструкции в так называемый микро-операции (microps), уже в Execution Core Reorder Buffer and Reservation Station привязывают (bind) микро-операции к портам в соответствии с правилами и ограничениями по типу операции, операндов и так далее. Соглашусь, что напрямую порты не делаю операций, но работают посредством Execution Unit и даже больше у этих EU есть свои latency/throughputs и определенный тип операций. Однако справедливости ради стоит добавить, что для вопроса оптимизации стоит оценивать нагрузку на порты, которые являться воротами к дальнейшему исполнению одному или нескольких EU. Вот именно эту нагрузку и пытается показать IACA. Очень хорошее дополнение в деталях! |
| 15.04.2009 03:15
Maxym Dmytrychenko (Intel)
|
Внес соответствующие коррективы в текст blog’а и целью более детального объяснения More comments , suggestions are welcome :) |
| 15.04.2009 04:55
ilnarb
|
Допустим, я встрою IACA_START и IACA_END, какая информация после этого будет предоставлена и что с ним делать? Или компилятор интел с++ сам будет оптимизировать как-то? Не нашел IACA User Guide ((( |
| 15.04.2009 05:43
Maxym Dmytrychenko (Intel)
|
User Guide доступен по http://software.intel.com/en-us/articles/intel-architecture-.....-download/ и дальше , Intel® Architecture Code Analyzer - User Guide Rev 1.0 там же примеры предоставленой инфы и несколько примеров оптимизации, раздел 5. Компилятор не будет использовать информацию от IACA, но программист - вполне :) |
| 15.04.2009 07:24
ilnarb
|
Спасибо! только пока я не очень понял в чем была оптимизация во втором примере если число циклов повысилось, критический путь удленнился. |
| 15.04.2009 14:15
Maxym Dmytrychenko (Intel)
|
5.2 Scalar Multiply • In Section 5.2.1 the throughput is 3 Cycles for 8 elements • In Section 5.2.2 the throughput is 4 Cycles for 16 elements, i.e. 2 cycles for 8 elements, yielding 1.5x speedup этот пример? |
| 15.04.2009 23:00
ilnarb
| ох оно вот в чем, при анролле добавили работы |
Dmitry Oganezov (Intel)
16,204
Статусных баллов:
16,204