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

> Что будет, если в потоке инструкций встретися такая, результат (эффект) исполнения которой зависит от внешнего по отношению к ядру устройства?

Её зависимости выделятся в отдельный поток, как и в любом другом случае. Абсолютно неважно что там и как - всё работает по одному и тому же принципу.

По какому принципу?

> > если поток занять ожиданием результата - зачем нужен OoO?

> Чтобы догрузить ядро чем-то ещё. Пока блоки ядра заняты одной задачей, другие можно занять другой.

Ты сам себе противоречишь.

В моём представлении, OoO нужен для того, чтобы не гнать впустую пайплайн, когда нам неизвестен результат одной инструкции в середине потока инструкций.

add ecx, ebx
in dx, al
shr esi, 2

Если не будет OoO, то во время выполнения in мы будем вынуждены гнать пустышки (bubble) по пайплайну вместо выполнения полезной работы.

В чём противоречие? И зачем же на самом деле нужен OoO?

Ты можешь вычислять сколько угодно md5 в рамках одного потока параллельно.

Для этого надо написать однопоточную программу, вычисляющую несколько md5 одновременно на одном ядре.

Если у нас будет гипотетическая ОС, знающая абсолютно всё про исполняющиеся процессы, используемой в машине процессор и умеющая перекомпилировать код за нулевое время, то SMT перестанет быть нужным — захотел пользователь считать две штуки md5 параллельно, ОС взяла и слила две задачи в одну, да так, что они в одно ядро поместились.

Пока же такой ОС нет, и эту работу выполняет CPU. SMT позволяет ОС предоставить процессору две задачи md5 вместо одной.

> Поток исполнения может заблокироваться, если для выполнения следующего блока инструкций нужен результат от предыдущего, который ещё не готов.

Всё куда интереснее.

Как же?

Опять же, полная херня - никакие твои днищенские х86-регистры не имеют отношения к load/store.

А где же ОС тогда хранит контекст процесса, и как можно восстановить/сохранить его без load/store?

Полная херня, таски итак будут переключатся - никто и нигде не выделяет таскам ядра монопольно.

Я не утверждаю, что переключений совсем не будет. Но их будет меньше.

переключение тасков происходит настолько редко

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

Твоё представление о том, как происходит процесс вычислений в современных CPU явно отличается от моего. Где я могу ознакомиться с тем, как всё устроено на самом деле?

> Что будет, если в потоке инструкций встретися такая, результат (эффект) исполнения которой зависит от внешнего по отношению к ядру устройства?

Её зависимости выделятся в отдельный поток, как и в любом другом случае. Абсолютно неважно что там и как - всё работает по одному и тому же принципу.

По какому принципу?

> > если поток занять ожиданием результата - зачем нужен OoO?

> Чтобы догрузить ядро чем-то ещё. Пока блоки ядра заняты одной задачей, другие можно занять другой.

Ты сам себе противоречишь.

В моём представлении, OoO нужен для того, чтобы не гнать впустую пайплайн, когда нам неизвестен результат одной инструкции в середине потока инструкций.

add ecx, ebx in dx, al shr esi, 2

Если не будет OoO, то во время выполнения in мы будем вынуждены гнать пустышки (bubble) по пайплайну вместо выполнения полезной работы.

В чём противоречие? И зачем же на самом деле нужен OoO?

Ты можешь вычислять сколько угодно md5 в рамках одного потока параллельно.

Для этого надо написать однопоточную программу, вычисляющую несколько md5 одновременно на одном ядре.

Если у нас будет гипотетическая ОС, знающая абсолютно всё про исполняющиеся процессы, используемой в машине процессор и умеющая перекомпилировать код за нулевое время, то SMT перестанет быть нужным — захотел пользователь считать две штуки md5 параллельно, ОС взяла и слила две задачи в одну, да так, что они в одно ядро поместились.

Пока же такой ОС нет, и эту работу выполняет CPU. SMT позволяет ОС предоставить процессору две задачи md5 вместо одной.

> Поток исполнения может заблокироваться, если для выполнения следующего блока инструкций нужен результат от предыдущего, который ещё не готов.

Всё куда интереснее.

Как же?

Опять же, полная херня - никакие твои днищенские х86-регистры не имеют отношения к load/store.

А где же ОС тогда хранит контекст процесса, и как можно восстановить/сохранить его без load/store?

Полная херня, таски итак будут переключатся - никто и нигде не выделяет таскам ядра монопольно.

Я не утверждаю, что переключений совсем не будет. Но их будет меньше.

переключение тасков происходит настолько редко

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

Твоё представление о том, как происходит процесс вычислений в современных CPU явно отличается от моего. Где я могу ознакомиться с тем, как всё устроено на самом деле?