Исправление kmeaw, (текущая версия) :
> Что будет, если в потоке инструкций встретися такая, результат (эффект) исполнения которой зависит от внешнего по отношению к ядру устройства?
Её зависимости выделятся в отдельный поток, как и в любом другом случае. Абсолютно неважно что там и как - всё работает по одному и тому же принципу.
По какому принципу?
> > если поток занять ожиданием результата - зачем нужен 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 явно отличается от моего. Где я могу ознакомиться с тем, как всё устроено на самом деле?
Исходная версия kmeaw, :
> Что будет, если в потоке инструкций встретися такая, результат (эффект) исполнения которой зависит от внешнего по отношению к ядру устройства?
Её зависимости выделятся в отдельный поток, как и в любом другом случае. Абсолютно неважно что там и как - всё работает по одному и тому же принципу.
По какому принципу?
> > если поток занять ожиданием результата - зачем нужен 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 явно отличается от моего. Где я могу ознакомиться с тем, как всё устроено на самом деле?