Почему увеличенная конвейерная глубина не всегда означает увеличенную пропускную способность?
Это - возможно, больше вопроса для обсуждения, но я думал, что stackoverflow мог быть правильным местом для выяснения у этого. Я изучаю понятие конвейерной обработки инструкции. Мне преподавали, что пропускная способность инструкции конвейера увеличена, после того как число настроек канала связи увеличено, но в некоторых случаях, пропускная способность не могла бы измениться. При каких условиях, это происходит? Я думаю, останавливаясь, и переходить могло быть ответом на вопрос, но интересно, пропускаю ли я что-то решающее.
5 ответов
Все действия могут быть остановлены другими инструкциями при ожидании результата или при промахах в кэше. Конвейерная обработка сама по себе не гарантирует, что операции полностью независимы. Вот отличная презентация о тонкостях архитектуры Intel / AMD x86: http://www.infoq.com/presentations/click -crash-course-modern-hardware
В нем очень подробно объясняются подобные вещи и рассматриваются некоторые решения о том, как еще больше повысить пропускную способность и скрыть задержку. JustJeff упомянул неупорядоченное выполнение для одного, и у вас есть теневые регистры, не отображаемые моделью программиста (более 8 регистров на x86), и у вас также есть предсказание ветвления.
Определенно срывы / пузыри в длинных трубопроводах вызывают огромную потерю пропускной способности. И, конечно же, чем длиннее конвейер, тем больше тактовых циклов тратится впустую.
Я долгое время пытался придумать другие сценарии, в которых более длинные конвейеры могут вызвать потерю производительности, но все возвращается к остановкам. (И количество исполнительных единиц и схемы выдачи, но они не имеют большого отношения к длине конвейера.)
Согласен. Самыми большими проблемами являются задержки (ожидание результатов от предыдущих инструкций) и неправильное предсказание ветвления. Если ваш конвейер имеет глубину 20 этапов, и вы зависаете в ожидании результатов условия или операции, вы будете ждать дольше, чем если бы ваш конвейер состоял всего из 5 этапов. Если вы предсказываете неправильную ветвь, вам нужно удалить из конвейера 20 инструкций, а не 5.
Я предполагаю, что у вас может быть глубокий конвейер, в котором несколько этапов пытаются получить доступ к одному и тому же оборудованию (ALU и т. Д.) , что приведет к снижению производительности, хотя, надеюсь, вы добавите достаточно дополнительных юнитов для поддержки каждого этапа.
Я также думаю, что увеличение конвейеризации сверх количества времени, которое потребовалось бы для выполнения самой длинной инструкции в серии, не приведет к увеличению производительности. Я думаю, что остановка и ветвление являются фундаментальными проблемами.
Параллелизм на уровне инструкций имеет убывающую отдачу. В частности, зависимости данных между инструкциями определяют возможный параллелизм.
Рассмотрим случай чтения после записи (известный в учебниках как RAW).
В синтаксисе, где первый операнд получает результат, рассмотрим такой пример.
10: add r1, r2, r3
20: add r1, r1, r1
Результат строки 10 должен быть известен к моменту начала вычислений в строке 10. Перенаправление данных смягчает эту проблему, но... только до того момента, когда данные становятся известны.