Что делает процессор, ожидая выборки из основной памяти

26

Предполагая, что запросы кэш-памяти l1 и l2 приводят к пропаданию, процессор останавливается до тех пор, пока к основной памяти не обращаются?

Я слышал об идее переключения на другой поток, если так, что используется, чтобы пробудить остановленный поток?

102948239408
источник
4
Какие исследования вы провели? Это, безусловно, информация, которая доступна. Я оставлю ответы экспертам, но не думаю, что переключение потоков - это полезная вещь. Как правило, переключение контекста на ЦП вызовет много обращений к памяти (и, следовательно, вероятно, пропадет кеш). Есть некоторые меры, такие как переупорядочение операций (с использованием конвейера), но, похоже, у остановки нет альтернативы.
Рафаэль
@Raphael Я в основном только что читал книги по компьютерной архитектуре, ARM System-on-Chip Architecture от Стива Фербера, вероятно, был наиболее полным из тех, что я прочитал полностью. Однако я начал читать компьютерную архитектуру: количественный подход. В нем описываются методы, позволяющие избежать сбоев, такие как переключение потоков, OOE и операции с памятью не по порядку, хотя он никогда не дает особого представления о тонкостях современного дизайна, поскольку, как и большинство учебников, они охватывают либо более старые архитектуры, либо дают смутные предположения о том, как эти вещи работают. реализованы и работают вместе.
102948239408
В продолжение моего вопроса, кеши, похоже, имеют небольшую задержку и являются детерминированными в своем ответе, но в случае обхода таблицы страниц сценария наихудшего случая для извлечения физического адреса, могут быть выполнены тысячи инструкций, некоторые из того же потока, извлеченного ILP. Какие аппаратные взаимодействия происходят с процессором, чтобы решить, что он может запланировать другой поток, и какой обмен данными используется для пробуждения этого потока, если это произойдет. Кроме того, если OoOE есть метод для работы с полной очередью результатов при переключении потоков?
102948239408
1
Из вашего вопроса не ясно, что вас интересуют особенности современных процессоров. Возможно, это не только оффтоп, но и конфиденциальная информация. С концепциями, мы можем помочь вам; они, вероятно, изменились меньше за десятилетия, чем реализации. Что касается вашего вопроса, пожалуйста, включите то, что вы знаете, и сформулируйте конкретный, концептуальный (или справочный запрос) вопрос.
Рафаэль
1
Я ответил об общих понятиях, но, судя по вашим комментариям, вы можете придерживаться более сложных соображений. Однако, если вы хотите получить более сложные ответы, вам нужно сделать свой вопрос более конкретным для конкретных архитектур и типов методов.
Жиль "ТАК - перестать быть злым"

Ответы:

28

Задержка памяти является одной из фундаментальных проблем, изучаемых в исследованиях компьютерной архитектуры.

Спекулятивное исполнение

Спекулятивное выполнение с проблемой неупорядоченных команд часто может найти полезную работу, чтобы заполнить задержку во время обращения к кэш-памяти L1, но обычно заканчивается полезная работа после 10 или 20 циклов или около того. Было несколько попыток увеличить объем работы, которую можно выполнить во время промаха с большим временем ожидания. Одна идея состояла в том, чтобы попытаться сделать ценностное предсказание (Липасти, Уилкерсон и Шен, (ASPLOS-VII): 138-147, 1996). Эта идея была очень модной в научных кругах академической архитектуры некоторое время, но, похоже, не работает на практике. Последней попыткой сохранить предсказание значения из мусорной корзины истории было предвкушение выполнения(Мутлу, Старк, Уилкерсон и Патт (HPCA-9): 129, 2003). В выполнении runahead вы понимаете, что ваши предсказания значений будут неправильными, но все равно спекулятивно выполняете их, а затем отбрасываете всю работу, основанную на предсказании, исходя из теории, что вы по крайней мере запустите некоторые предварительные выборки для того, что в противном случае было бы кешем L2 промахов. Оказывается, ранада впустую тратит столько энергии, что просто не стоит этого.

Последний подход в этом направлении, который может получить некоторую популярность в промышленности, заключается в создании чрезвычайно длинных буферов переупорядочения. Инструкции выполняются спекулятивно на основе прогнозирования ветвлений, но прогнозирование значений не выполняется. Вместо этого все инструкции, которые зависят от загрузки с большим временем ожидания, сидят и ждут в буфере переупорядочения. Но поскольку буфер переупорядочения настолько велик, вы можете продолжать извлекать инструкции, если предиктор ветвления делает достойную работу, иногда вы сможете найти полезную работу намного позже в потоке команд. Влиятельным исследовательским документом в этой области были Continuous Flow Pipelines(Шринивасан, Раджвар, Аккари, Ганди и Аптон (АСПЛОС-XI): 107-119, 2004). (Несмотря на то, что все авторы принадлежат Intel, я думаю, что эта идея получила большее распространение в AMD.)

Многопоточность

Использование нескольких потоков для обеспечения устойчивости к задержкам имеет гораздо более длительную историю и гораздо больший успех в промышленности. Все успешные версии используют аппаратную поддержку многопоточности. Самая простая (и наиболее успешная) версия этого - то, что часто называют FGMT ( мелкозернистая многопоточность ) или чередованная многопоточность . Каждое аппаратное ядро ​​поддерживает несколько потоковых контекстов ( контекст по сути является состоянием регистра, включая регистры, такие как указатель команд и любые регистры неявных флагов). В мелкозернистом многопоточном процессоре каждый поток обрабатывается в-приказ. Процессор отслеживает, какие потоки остановились при пропадании нагрузки с большим временем ожидания, а какие готовы к следующей инструкции, и использует простую стратегию планирования FIFO для каждого цикла, чтобы выбрать, какой готовый поток выполнить этот цикл. Первым примером этого в широком масштабе были HEP-процессоры Burton Smith (Burton Smith продолжил разработку суперкомпьютера Tera, который также был мелкозернистым многопоточным процессором). Но идея уходит гораздо дальше, в 1960-е годы, я думаю.

FGMT особенно эффективен при потоковых рабочих нагрузках. Все современные графические процессоры (графические процессоры) являются многоядерными, где каждое ядро ​​является FGMT, и эта концепция также широко используется в других вычислительных областях. Sun T1 также был многоядерным FMGT, как и Intel Xeon Phi (процессор, который до сих пор называют «MIC» и раньше называли «Larabee»).

Идея одновременной многопоточности (Tullsen, Eggers и Levy, (ISCA-22): 392-403, 1995) объединяет аппаратную многопоточность со спекулятивным исполнением. Процессор имеет несколько контекстов потока, но каждый поток выполняется спекулятивно и не по порядку. Более сложный планировщик может затем использовать различные эвристические методы для извлечения из потока, который, скорее всего, будет полезен ( Малик, Агарвал, Дар и Фрэнк, (HPCA-14: 50-61), 2008 ). Некоторая крупная полупроводниковая компания начала использовать термин гиперпоточность для одновременной многопоточности, и это имя, по-видимому, является наиболее широко используемым в наши дни.

Микроархитектурные проблемы низкого уровня

После перечитывания ваших комментариев я понял, что вы также заинтересованы в передаче сигналов между процессором и памятью. Современные кэши обычно допускают одновременное выполнение нескольких промахов. Это называется кешем без блокировки (Kroft, (ISCA-8): 81-87, 1981). (Но документ трудно найти в Интернете, и его довольно сложно прочитать. Краткий ответ: ведется много бухгалтерского учета, но вы просто с этим справляетесь. Структура аппаратного учета называется MSHR (отсутствует информация / регистр хранения статуса). ), это имя Крофт дал в своей статье 1981 года.)

Блуждающая логика
источник
Спасибо, действительно исчерпывающий ответ, попробую заглянуть в кеш без блокировки. Мой плохо сформулированный вопрос действительно пытался подтвердить, что процессоры продолжали загружаться и сохраняться во время доступа к основной памяти и какие микроархитектурные методы использовались для этого.
102948239408
+1, 1. Действительно ли это обработка ствола, если не используется циклическое планирование? Википедия делает это синонимом FGMT. (Я могу согласиться с применением «процессора бочек» к циклическому набору с пропуском, хотя это нарушает аналогию, так как отсутствующий стержень (ср. Неготовая нить) не сокращает окружность бочки. (Я думаю, что «настоящие» бочечные процессоры были редко - возможно, периферийный процессор для CDC 6600? - потому что они тратят впустую цикл, но это упрощает оборудование.) 2. Упоминание SoEMT, например, Hyper-Threading от Itanium и Northstar и др. от IBM, кажется особенно уместным, учитывая этот вопрос.
Пол А. Клейтон
@ 102948239408, еще одна вещь, которую вы могли бы найти в Google, это такие термины, как «попадание под промахом» и «промахнуться под промахом» (другой вариант - «остановка под промахом», но я только что попробовал и, похоже, ничего полезного не возвращает.) Термины, которые в настоящее время используются (некоторыми) архитекторами для различных вариантов того, что может разрешить кеш.
Блуждающая логика
@ PaulA.Clayton, терминология определенно не моя сильная сторона. Я согласен с вами, что обработка ствола должна означать циклический перебор. Но я не могу придумать ни одного другого термина, который означает: чередование по циклам группы потоков в порядке (что делают все графические процессоры, Xeon Phi и Sun T1). Это ФГМТ? Я всегда думал, что FGMT включает SMT (то есть не указывает, что потоки должны выполняться по порядку), но, может быть, FGMT лучше, чем «процессор бочонка» для этого случая?
Блуждающая логика
В статье о процессоре Barrel из Википедии говорится: «также известный как« чередующийся »или« мелкозернистый »временный многопоточный режим», поэтому IMT и FGMT являются, по крайней мере, признанными терминами. Я думаю, что я прочитал «мелкозернистый» больше, чем «чередующийся», но чередующийся не является редкостью. Я обычно использовал FG (для меня «зернистость» подразумевает большее разделение, чем обеспечивает SMT); Преимущество FG в том, что чередование может применяться к SoEMT. Я подозреваю, что это всего лишь изменение в использовании «бочкообразного процессора», которое мне придется оскалить (оскалить) и нести.
Пол А. Клейтон
16

Короткий ответ: ничего, процессор глохнет.

Там не так много возможностей. Переключение на другую задачу на самом деле не вариант по двум причинам. Это дорогостоящая операция, и поскольку текущая задача и другая задача конкурируют за место в кеше, переключение на другую задачу может само по себе потребовать доступ к основной памяти, а также может вернуться к исходной задаче. Кроме того, для этого потребуется задействовать операционную систему, поэтому процессор должен будет инициировать некоторую форму прерывания или прерывания - фактически процессор будет переключаться на некоторый код ядра.

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

Тем не менее современные компьютеры включают в себя множество методов, позволяющих сократить время, затрачиваемое процессором на ожидание основной памяти. Срыв происходит, но только тогда, когда его невозможно избежать.

Один из методов - спекулятивные выборки : процессор пытается угадать, к какой ячейке памяти будет осуществляться доступ, и забирает ее для кэширования заранее. Например, циклы над блоком памяти являются общими, поэтому, если строки кэша были загружены для адресов памяти 0x12340000, 0x12340010 и 0x12340020, было бы неплохо загрузить строку для 0x12340030. Компилятор может помочь, генерируя инструкции предварительной выборки, которые похожи на нагрузки, за исключением того, что они передают данные только из основной памяти в кэш, а не в регистр процессора.

Другая техника - умозрительное исполнение . Процессор начинает выполнять следующую инструкцию до загрузки. В любом случае это происходит естественным образом из-за конвейеризации инструкций. Только инструкции, которые не зависят от загруженного значения, могут быть выполнены таким образом: процессор должен выполнить анализ зависимостей. Для условных инструкций (например, загрузка r1; переход, если r1 ≠ 0), процессоры используют эвристику предсказания переходов, чтобы угадать, какое значение будет. Спекулятивное выполнение после загрузки может потребоваться перемотать в случае, если загрузка вызывает прерывание.

Некоторые архитектуры, такие как Itanium, облегчают выполнение инструкций в удобном порядке, позволяя переупорядочивать команды по умолчанию: вместо того, чтобы состоять из последовательности элементарных инструкций, которые семантически выполняются одна за другой, программы состоят из очень длинных командных слов : одна инструкция включает множество операций, которые должны выполняться параллельно различными компонентами процессора.

Переключение на другой поток происходит в гиперпоточности , встречающейся на высокопроизводительных процессорах x86. Это метод проектирования аппаратного обеспечения: каждое ядро ​​процессора содержит два отдельных банка регистров (каждый соответствует контексту задачи), но один экземпляр других элементов, так что он может поддерживать два независимых потока выполнения, но эффективно выполнять команды только от одного в время. Пока один поток останавливается, другой поток продолжается. С точки зрения программного обеспечения существует два независимых процессора; Просто так получилось, что эти процессоры имеют много общих компонентов.

Обмен - это еще один уровень в иерархии кеша памяти: основная память может рассматриваться как кеш для пространства подкачки. При замене механизмы и показатели производительности различаются. Если для задачи требуется загрузка данных из подкачки, инструкция загрузки запускает ловушку, которая выполняет код ядра для выделения страницы в ОЗУ и загрузки ее содержимого с диска. Пока это происходит, ядро ​​вполне может решить переключиться на другую задачу.

Жиль "ТАК - перестань быть злым"
источник
В отличие от первого и второго до последнего абзаца, «хитрость» в том, что с гиперпоточностью не должно происходить никакого реального переключения контекста, верно? Процессор полностью поддерживает два контекста одновременно.
Рафаэль
1
@Raphael Верно: что касается программного обеспечения, для всего, кроме производительности, есть два процессора.
Жиль "ТАК ... перестать быть злым"
У многопоточного ЦП есть много полунезависимых исполнительных блоков (целочисленные и сумматоры с плавающей запятой, множители и т. Д.), И я думаю, что оба контекста могут использовать отдельные исполнительные блоки одновременно - хотя на 100% не уверены в этом.
Рассел Борогове
@RussellBorogove Да, я не упоминал об этом , потому что даже не-hyperthreaded процессоры могут иметь несколько ALU / FPU / ... и , наоборот , отдельные ядра иногда разделяют FPU и т.д.
Жиля SO- перестать быть злым »
5

Ответ на этот вопрос зависит от конкретной архитектуры. В то время как многие процессоры останавливаются (ARM, x86 без гиперпоточности и т. Д.), Так как им требуется слишком много времени для переключения потоков, это не тот подход, который используется в каждой архитектуре. В некоторых архитектурах каждый поток, запланированный на ЦП, имеет свой собственный независимый регистровый файл, поэтому процессор может просто выполнять работу из потока, который не ожидает доступа к памяти. Насколько я понимаю, это в некоторой степени то, что делает гиперпоточность x86 (используя только 2 потока), но это гораздо чаще встречается в GPGPUархитектуры. В конкретном случае CUDA, по меньшей мере, десятки, если не сотни, перекосов потоков обычно загружаются в данный мультипроцессор в любой момент времени, причем каждый поток (сотни или тысячи из них) имеет свои собственные регистры. Это позволяет архитектуре выполнять инструкцию из другого потока в следующем цикле, когда данный поток выдает доступ к памяти. Таким образом, до тех пор, пока загружено достаточно много потоков, ядра процессора никогда не простаивают для доступа к памяти. См. Рекомендации по производительности и Иерархия памяти для получения дополнительной информации.

reirab
источник