Расчет среднего количества циклов на инструкцию с учетом времени выполнения, количества инструкций и тактовой частоты

Итак, я изучаю компьютерную архитектуру, где мы должны учитывать разные процессоры и их тактовые частоты, и я не могу не чувствовать, что мои расчеты ошибочны при вычислении среднего CPI. Для одного такого процесса мне дается:

  • количество инструкций 1.0E9
  • Время выполнения 1,5 с для программы компилятора A
  • и тактовая частота процессора 8.0E9 Гц.

Мое переработанное уравнение - CPI = (Execution Time * Clock Rate)/Instruction Count.

Подставив значения, я понял, что средний CPI для программы компилятора A равен 12. Однако это намного выше, чем у других практических задач. Мне было интересно, верны ли мои расчеты или нет, и если да, то почему ИПЦ такой высокий?


person Zakenmaru    schedule 11.02.2020    source источник
comment
Результат выглядит правильным. Это теоретический пример, поэтому я бы не стал беспокоиться о том, что буду слишком высоко. Черт возьми, разделение на реальном процессоре x86 может занять более 12 циклов, и это даже не учитывая обращения к памяти.   -  person Jester    schedule 11.02.2020
comment
@Jester Хорошо, спасибо!   -  person Zakenmaru    schedule 11.02.2020


Ответы (1)


Если бы это было реальным, а не выдуманным случайным примером:

Я бы ожидал, что процессор с тактовой частотой 8 ГГц будет сильно конвейерным и, следовательно, будет иметь высокие штрафы за неверные прогнозы филиалов и другие задержки. И, вероятно, более высокая задержка для более сложных инструкций. (Предположительно задержка в один цикл для add и других простых инструкций ALU; тактовая частота настолько высока, что вы не можете этого сделать, имеет смысл только в том случае, если вам нужна частота 8 ГГц для маркетинга, а не для реальной производительности.)

Кроме того, для данной скорости DRAM промах в кэше имеет фиксированное время в наносекундах. С более высокими тактовыми частотами ядра гораздо больше циклов ядра тратится на ожидание того же промаха в кэше (т. Е. Большая задержка памяти для выполнения вне очереди, чтобы попытаться скрыть).

См. Также 90-минутное руководство по современным микропроцессорам! - это был бы полный "демон скорости" "дизайн, противоположный" умному ".


Но даже тогда CPI, равный 12, вероятно, не будет типичным (например, для SPECint2017) для любого разумного проекта, который кто-то возьмет на себя построение. Но помните, это для одной конкретной программы. Очень высокий CPI (низкий IPC) также является признаком неэффективного программного обеспечения (или, по крайней мере, делает что-то неизбежно медленное), например тратить много времени на просмотр связанных списков, которые отсутствуют в кеше. Адрес для следующей загрузки зависит от предыдущей загрузки, поэтому он не может даже запуститься, пока не будет получен из внешнего кеша или даже полностью из памяти.

(Другие структуры данных также включают поиск указателей, например двоичные деревья. Поиск в огромном двоичном дереве включает как поиск указателей, так и (обычно) неверные предсказания ветвей. Двоичный поиск в плоском массиве или неявном дереве, в котором узлы находятся в известных положениях массива, позволяет программная предварительная выборка из двух возможностей перед следующим шагом, используя дополнительную полосу пропускания для уменьшения задержки за счет использования преимуществ параллелизма на уровне памяти, на который способно большинство HW.)


Или, конечно, поскольку это всего лишь теоретический пример, не имеющий никакого отношения к здравомыслию, ЦП может быть настолько глупо неэффективным, насколько мы хотим: возможно, он микрокодирован (а не конвейерен), как оригинальный 8086 и другие микропроцессоры той эпохи, и выполняет инструкции по следующие микрокодированные шаги, каждый из которых занимает тактовый цикл. (например, детали производительности Z80 были известны с точки зрения внутренних состояний по сравнению с тактовыми циклами, а для обычных инструкций потребовалось несколько).


Или, может быть, это архитектура с векторными инструкциями SIMD в стиле Cray старой школы, где одна инструкция (с парой входных указателей) может заменить целый цикл над массивами чисел с плавающей запятой. (Таким образом, высокопроизводительные процессоры могут использовать преимущества более широких путей передачи данных без необходимости использования другого машинного кода, как мы это делаем для современных SIMD с короткими векторами, таких как x86 SSE / AVX / AVX512, чтобы использовать преимущества нового HW с более широкими модулями SIMD add / mul / FMA .)

person Peter Cordes    schedule 11.02.2020
comment
Вот о чем я думал; процессор должен был бы быть действительно плохим, если бы CPI был таким высоким. Это как раз то, что мне дала проблема, и каждый раз я получал 12. - person Zakenmaru; 11.02.2020
comment
@Zakenmaru: Вы могли бы легко написать программу, которая запускает 12 CPI на Skylake или Zen (очень умный дизайн). Например, выполните поиск в двоичном дереве, узкие места при пропуске кэша задержка (не пропускная способность, параллелизм на низком уровне памяти) и неправильные прогнозы ветвлений. То, что процессор действительно плохой, - лишь один из множества способов объяснить это. - person Peter Cordes; 11.02.2020
comment
@Zakenmaru: Но да, типичный CPI ниже 1.0 для основных процессоров с такими рабочими нагрузками, как SPECint2017 / SPECfp2017 (research rel_cpu2017_Benchmark> / публикации / показывает, что Haswell Xeon достигает 1,7 IPC = 1 / 1,7 CPI). Чаще говорят о IPC, особенно для суперскалярных дизайнов. Так или иначе, выбора рабочей нагрузки более чем достаточно для объяснения CPI от 0,2 до 20 или более 100, если мы говорим о ручной сборке или рабочей нагрузке FP, которая требует поддержки микрокода для получения субнормальных результатов на каждом входе. - person Peter Cordes; 11.02.2020