Могут ли интерпретируемые языки использовать слоты задержки?

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

(Обратите внимание: если что-то, что я сказал выше, отражает пробел в моем понимании, пожалуйста, исправьте это, потому что эти концепции являются новыми для меня).


delayed-execution interpreted-language computer-architecture
person Kvass    schedule 11.12.2013    source источник
comment
Большинство современных процессоров полагаются на автоматическое переупорядочивание инструкций и в любом случае не предоставляют программе такие функции, как слоты задержки.   -  person oakad    schedule 11.12.2013

Ответы (2)


arrow_upward
1
arrow_downward

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

Также обратите внимание, что на современном аппаратном обеспечении большая часть простого переупорядочения бессмысленна - механизм выполнения не по порядку все равно внутренне переупорядочивает код, так что каждая инструкция может выполняться после разрешения ее зависимостей данных. Что касается зависимости от управления, на рынке есть действительно хорошие предсказатели ветвлений, поэтому вы почти не останавливаетесь — вы просто размышляете и сбрасываете в случае, если ошиблись (что того стоит, поскольку в большинстве случаев точность предсказания может достигать ~ 95%).

У переупорядочивания по-прежнему есть важное преимущество, но оно не для устранения пузырей, а в основном для подъема нагрузки, перемещения кода, не зависящего от циклов, и устранения ложных зависимостей памяти, которые HW не может переупорядочить самостоятельно. Однако это не просто переупорядочение, которое вы можете выполнить во время интерпретации, для этого вам понадобится реальная компиляция или джиттинг.

person Leeor    schedule 11.12.2013
comment
Ниггл: Stanford MIPS использовал ассемблер для выполнения ограниченного переупорядочивания команд (и упаковки). набор инструкций на языке ассемблера, определяет инструкции, которые не упакованы и не имеют конвейерных зависимостей или задержек ветвления. (Проектирование высокопроизводительного процессора СБИС, Hennessy et al., 1983, TR#236). Намерение состояло в том, чтобы обеспечить совместимость на уровне сборки и машинный код, зависящий от реализации, при этом позволяя вносить изменения в реализацию. (В основном это просто историческая сноска.) - person Paul A. Clayton; 11.12.2013
comment
@PaulA.Clayton, существует множество архитектур потоков данных и VLIW, которые позволяют вам выполнять код с заранее определенными зависимостями, поэтому вы можете изменить порядок кода по своему усмотрению. Я думаю, что большинство из них используют специализированные компиляторы, которые делают большую часть этой работы за вас. - person Leeor; 11.12.2013

arrow_upward
0
arrow_downward

Вспомните компьютер Minecraft. По сути, это интерпретатор: программа, читающая инструкции и выбирающая, какие внутренние функции/процедуры выполнять свои входные директивы в реальном времени, а не посредством компиляции.

Сам интерпретатор — в данном случае программа minecraft — может использовать настройки уровня процессора, но приложение — компьютер Redstone — не может.

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

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

Но нет, чисто интерпретируемый язык не может.

person kfsone    schedule 11.12.2013