Здравствуйте, Sinclair, Вы писали:

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

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


S>Как предполагается переключать сотни потоков?

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

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


S>Иметь регистровый банк в несколько тысяч регистров

А он де-факто уже есть даже в мейнстримовых архитектурах на уровне кеша 0-го уровня — в этом банке хранятся как "реальные" регистры, куда ОоО совершает отображение-переименование, так и таблицы разметки виртуальной памяти. Просто требуется этот подход тоже довести до абсурда банально через экстенсивное увеличение размера кеша 0-го уровня и снабдив его огромной ассоциативной схемой отображения, связывающей участки этого кеша с "логическими аппаратными" потоками — его системными и прикладными регистрами. (в кавычках немного оксюморон, но такова задумка, насколько я понял)


S>или восстанавливать все регистры из памяти?

В случае переполнения ресурсов — а как же? ))


S>Ну, тогда переключение будет на порядок дороже гипертрединга.

Ну открой в страницах браузера многие десятки динамических 3D-визуализаций даже на самой современной видеокартейке — и начнутся запинания. ))
Никакие ресурсы не бесконечны, конечно.

Но для неких актуальных классов задач они могут быть в пределах достаточного, чтобы обеспечить эффективное решение некоего разумного количества этих задач одновременно.


V>>В общем, ожидаемая схема
S>Непонятно, откуда взята "ожидаемая схема". В публично доступных источниках я видел только финансовый аспект этой схемы — и он-то как раз сомнений особо не вызывает.

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

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

Они просто отбросили пресловутый "груз легаси" и пытаются на актуальных кол-вах транзисторов на кристалле воплотить с 0-ля сочетание нескольких уже обкатанных схем.

С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда", до практически-достижимого максимума за счёт экстенсивного наращивания кол-ва АЛУ, наиболее мощного механизма спекулятивного исполнения на сегодня и механизма явной предзагрузки памяти (тоже в топах на сегодня, потягаться могут только Cell-процы в видеоприставках). Даже их способ ветвления в одной команде, когда исполняются две ветки, а в память записывается результат исполнения лишь одной по результату вычисления логического выражения — это тоже уже было до них в сигнальных процах. Просто они сделали это чуть качественней, бо сигнальные процы не могли себе позволить быть дорогими, а ЦП может!

Здравствуйте, Sinclair, Вы писали:

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

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


S>Как предполагается переключать сотни потоков?

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

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


S>Иметь регистровый банк в несколько тысяч регистров

А он де-факто уже есть даже в мейнстримовых архитектурах на уровне кеша 0-го уровня — в этом банке хранятся как "реальные" регистры, куда ОоО совершает отображение-переименование, так и таблицы разметки виртуальной памяти. Просто требуется этот подход тоже довести до абсурда банально через экстенсивное увеличение размера кеша 0-го уровня и снабдив его огромной ассоциативной схемой отображения, связывающей участки этого кеша с "логическими аппаратными" потоками — его системными и прикладными регистрами. (в кавычках немного оксюморон, но такова задумка, насколько я понял)


S>или восстанавливать все регистры из памяти?

В случае переполнения ресурсов — а как же? ))


S>Ну, тогда переключение будет на порядок дороже гипертрединга.

Ну открой в страницах браузера многие десятки динамических 3D-визуализаций даже на самой современной видеокартейке — и начнутся запинания. ))
Никакие ресурсы не бесконечны, конечно.

Но для неких актуальных классов задач они могут быть в пределах достаточного, чтобы обеспечить эффективное решение некоего разумного количества этих задач одновременно.


V>>В общем, ожидаемая схема
S>Непонятно, откуда взята "ожидаемая схема". В публично доступных источниках я видел только финансовый аспект этой схемы — и он-то как раз сомнений особо не вызывает.

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

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

Они просто отбросили пресловутый "груз легаси" и пытаются на актуальных кол-вах транзисторов на кристалле воплотить с 0-ля сочетание нескольких уже обкатанных схем.

С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда", до практически-достижимого максимума за счёт экстенсивного наращивания кол-ва АЛУ, наиболее мощного механизма спекулятивного исполнения на сегодня и механизма явной предзагрузки памяти (тоже в топах на сегодня, потягаться могут только Cell-процы в видеоприставках). Даже их способ ветвления в одной команде, когда исполняются две ветки, а в память записывается результат исполнения лишь одной по результату вычисления логического выражения — это тоже уже было до них в сигнальных процах. Просто они сделали это чуть качественней, бо сигнальные процы не могли позволить себе быть дорогими, а ЦП может!