История изменений

С тех пор, как поняли, что VLIW на DRAM не работает, и продвинутым компилятором это исправлять бессмысленно. Суть OoOE в том, что это способ работы с задержками DRAM: выполняется та инструкция, для которой уже пришли данные из памяти

Если у тебя производительность упирается в доступ к RAM, то тебе не поможет ничего. В x86 проблема была искуственно создана, поскольку на уровне кэша происходит упорядочивание операций, из-за чего ждать приходилось не просто одну ячейку, а целую последовательность. В ARM такого нет, потому задержки намного меньше.

Да, они все равно не нулевые, а еще есть всякие там умножения-деления, которые долго выпоняются, особенно на вещественных числах — тут можно что-то заоптиизировать. Более того, в ARM возможно начать интерпретировать следующую инструкцию до интерпретации предыдущей — это не значит «выполнять», то есть, прямо-таки пытаться читать операнды, которые еще не готовы. Но какой-нибудь безусловный прыжок от операндов не зависит, например. Даже для условных прыжков ARM может прогрузить в конвееры обе ветки — это всё еще не выполнение инструкций (это упомянутая суперскалярность).

То есть, пространства для оптимизаций на армах было достаточно без внеочередного выполнения — потому я и возражал по поводу «кремний нужен был на OoOE». У Alpha не было внеочередного выполнения, а она укатывала x86 в хламину. Правда, там были такие волшебные штуки, из-за которых в ядре линя до сих пор есть макросы READ_ONE/WRITE_ONCE — поскольку на альфе зависящие операнды, как то указатель и значение по этому указателю, могли приходить в произвольном порядке, из-за чего возможно было прочитать значение по указателю до чтения этого указателя — причем, это даже звучит как внеочередное выполнение, но на самом деле это поочередное выполнение, но на разных кэшах, которые видят изменения памяти в произвольном порядке.

С тех пор, как поняли, что VLIW на DRAM не работает, и продвинутым компилятором это исправлять бессмысленно. Суть OoOE в том, что это способ работы с задержками DRAM: выполняется та инструкция, для которой уже пришли данные из памяти

Если у тебя производительность упирается в доступ к RAM, то тебе не поможет ничего. В x86 проблема была искуственно создана, поскольку на уровне кэша происходит упорядочивание операций, из-за чего ждать приходилось не просто одну ячейку, а целую последовательность. В ARM такого нет, потому задержки намного меньше.

Да, они все равно не нулевые, а еще есть всякие там умножения-деления, которые долго выпоняются, особенно на вещественных числах — тут можно что-то заоптиизировать. Более того, в ARM возможно начать интерпретировать следующую инструкцию до интерпретации предыдущей — это не значит «выполнять», то есть, прямо-таки пытаться читать операнды, которые еще не готовы. Но какой-нибудь безусловный прыжок от операндов не зависит, например. Даже для условных прыжков ARM может прогрузить в конвееры обе ветки — это всё еще не выполнение инструкций.

То есть, пространства для оптимизаций на армах было достаточно без внеочередного выполнения — потому я и возражал по поводу «кремний нужен был на OoOE». У Alpha не было внеочередного выполнения, а она укатывала x86 в хламину. Правда, там были такие волшебные штуки, из-за которых в ядре линя до сих пор есть макросы READ_ONE/WRITE_ONCE — поскольку на альфе зависящие операнды, как то указатель и значение по этому указателю, могли приходить в произвольном порядке, из-за чего возможно было прочитать значение по указателю до чтения этого указателя — причем, это даже звучит как внеочередное выполнение, но на самом деле это поочередное выполнение, но на разных кэшах, которые видят изменения памяти в произвольном порядке.