Сообщение Re[32]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 17.06.2025 0:05
Изменено 18.06.2025 0:32 vdimas
Re[32]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, netch80, Вы писали:
V>>Нужны многие десятки (сотни?) аппаратных потоков, чтобы это имело смысл.
N>Или же нужно просто не тратиться на переключение.
Дык, я именно об этом и говорю, что переключения как таково зачастую не будет, бо аппаратных потоков должно быть дохерища.
N>Например, те же регистровые блоки хитроспрятанным образом хранятся в процессоре, если он того хочет.
В кеше L0 всё, где и таблица разметки вирт.памяти.
N>Это как раз сделано в Intel VMX.
И опять это немножко не то, хоть и близко.
Понятно, что любые околопоточные вещи с хранимым контекстом потока можно притянуть за уши за аналогию, но ключевое не это, а способ запуска-останова аппаратных потоков.
N>Супервизор говорит VMLAUNCH и появляется состояние, когда завершается — зовёт VMCLEAR.
Да, программно в том числе, конечно, но больше интересует по аппаратным барьерам, например, как необходимо сводить рабочие потоки при распараллеливании циклов.
А этот барьер — просто ячейка памяти в L0, которую уменьшает счетчик, их динамически-выделяемых должно уметь создаваться немеряно для прикладных целей, сколько хатит некоей свободной для приложений памяти в L0.
N>Процессор может хранить состояния разных VM, что сейчас неактивны, а может не хранить. (Думаю, большинство текущих не хранят
Именно так.
Потоков как неких хранимых и готовых для запуска "контекстов исполнения" должно быть намного больше, чем хватает выч.блоков для одновременного их исполнения.
Плюс необходим аппаратный форк, да еще с коэф. большим 2-х — вот тебе бесплатное распараллеливание задачи навроде умножения матриц, а то сейчас само создание потоков относительно дорого.
N>Вот в это я как-то больше верю. Но смущают 1) объём этих регистровых файлов (реальный), 2) сложность переключения при OoO.
OoO — это автомат без памяти о прошлом.
Он банально на каждом шаге сортирует независимые (если они независимые) операции по времени их ожидаемой готовности к исполнению.
N>С остановкой конвейера оно понятно
ИМХО, не получится организовать такие же выч. конвейеры как в нынешних суперскалярах в такой архитектуре, придётся разбить на конвейер декодера-предзагрузчика потока (как часть области памяти контекста, при вытеснении потока в обычную память, что делает ОС при оперировании ресурсами, конвейер сбрасывается), и конвейеры векторных инструкций, привязанные к самим выч.автоматам, и там без вариантов — надо дождаться отработки многотактовой векторной инструкции, чтобы снимать поток. А некие выч.блоки не требуют личного конвейера, типа АЛУ простых арифметических и логических операций, бо такие операции однотактные и даже можно кучу таких операций за такт в одном потоке силами OoO.
V>>Нужны многие десятки (сотни?) аппаратных потоков, чтобы это имело смысл.
N>Или же нужно просто не тратиться на переключение.
Дык, я именно об этом и говорю, что переключения как таково зачастую не будет, бо аппаратных потоков должно быть дохерища.
N>Например, те же регистровые блоки хитроспрятанным образом хранятся в процессоре, если он того хочет.
В кеше L0 всё, где и таблица разметки вирт.памяти.
N>Это как раз сделано в Intel VMX.
И опять это немножко не то, хоть и близко.
Понятно, что любые околопоточные вещи с хранимым контекстом потока можно притянуть за уши за аналогию, но ключевое не это, а способ запуска-останова аппаратных потоков.
N>Супервизор говорит VMLAUNCH и появляется состояние, когда завершается — зовёт VMCLEAR.
Да, программно в том числе, конечно, но больше интересует по аппаратным барьерам, например, как необходимо сводить рабочие потоки при распараллеливании циклов.
А этот барьер — просто ячейка памяти в L0, которую уменьшает счетчик, их динамически-выделяемых должно уметь создаваться немеряно для прикладных целей, сколько хатит некоей свободной для приложений памяти в L0.
N>Процессор может хранить состояния разных VM, что сейчас неактивны, а может не хранить. (Думаю, большинство текущих не хранят
Именно так.
Потоков как неких хранимых и готовых для запуска "контекстов исполнения" должно быть намного больше, чем хватает выч.блоков для одновременного их исполнения.
Плюс необходим аппаратный форк, да еще с коэф. большим 2-х — вот тебе бесплатное распараллеливание задачи навроде умножения матриц, а то сейчас само создание потоков относительно дорого.
N>Вот в это я как-то больше верю. Но смущают 1) объём этих регистровых файлов (реальный), 2) сложность переключения при OoO.
OoO — это автомат без памяти о прошлом.
Он банально на каждом шаге сортирует независимые (если они независимые) операции по времени их ожидаемой готовности к исполнению.
N>С остановкой конвейера оно понятно
ИМХО, не получится организовать такие же выч. конвейеры как в нынешних суперскалярах в такой архитектуре, придётся разбить на конвейер декодера-предзагрузчика потока (как часть области памяти контекста, при вытеснении потока в обычную память, что делает ОС при оперировании ресурсами, конвейер сбрасывается), и конвейеры векторных инструкций, привязанные к самим выч.автоматам, и там без вариантов — надо дождаться отработки многотактовой векторной инструкции, чтобы снимать поток. А некие выч.блоки не требуют личного конвейера, типа АЛУ простых арифметических и логических операций, бо такие операции однотактные и даже можно кучу таких операций за такт в одном потоке силами OoO.
Re[32]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, netch80, Вы писали:
V>>Нужны многие десятки (сотни?) аппаратных потоков, чтобы это имело смысл.
N>Или же нужно просто не тратиться на переключение.
Дык, я именно об этом и говорю, что переключения как такового зачастую не будет, бо аппаратных потоков должно быть дохерища.
N>Например, те же регистровые блоки хитроспрятанным образом хранятся в процессоре, если он того хочет.
В кеше L0 всё, где и таблица разметки вирт.памяти.
N>Это как раз сделано в Intel VMX.
И опять это немножко не то, хоть и близко.
Понятно, что любые околопоточные вещи с хранимым контекстом потока можно притянуть за уши за аналогию, но ключевое не это, а способ запуска-останова аппаратных потоков.
N>Супервизор говорит VMLAUNCH и появляется состояние, когда завершается — зовёт VMCLEAR.
Да, программно в том числе, конечно, но больше интересует по аппаратным барьерам, например, как необходимо сводить рабочие потоки при распараллеливании циклов.
А этот барьер — просто ячейка памяти в L0, которую уменьшает счетчик, их динамически-выделяемых должно уметь создаваться немеряно для прикладных целей, сколько хатит некоей свободной для приложений памяти в L0.
N>Процессор может хранить состояния разных VM, что сейчас неактивны, а может не хранить. (Думаю, большинство текущих не хранят
Именно так.
Потоков как неких хранимых и готовых для запуска "контекстов исполнения" должно быть намного больше, чем хватает выч.блоков для одновременного их исполнения.
Плюс необходим аппаратный форк, да еще с коэф. большим 2-х — вот тебе бесплатное распараллеливание задачи навроде умножения матриц, а то сейчас само создание потоков относительно дорого.
N>Вот в это я как-то больше верю. Но смущают 1) объём этих регистровых файлов (реальный), 2) сложность переключения при OoO.
OoO — это автомат без памяти о прошлом.
Он банально на каждом шаге сортирует независимые (если они независимые) операции по времени их ожидаемой готовности к исполнению.
N>С остановкой конвейера оно понятно
ИМХО, не получится организовать такие же выч. конвейеры как в нынешних суперскалярах в такой архитектуре, придётся разбить на конвейер декодера-предзагрузчика потока (как часть области памяти контекста, при вытеснении потока в обычную память, что делает ОС при оперировании ресурсами, конвейер сбрасывается), и конвейеры векторных инструкций, привязанные к самим выч.автоматам, и там без вариантов — надо дождаться отработки многотактовой векторной инструкции, чтобы снимать поток. А некие выч.блоки не требуют личного конвейера, типа АЛУ простых арифметических и логических операций, бо такие операции однотактные и даже можно кучу таких операций за такт в одном потоке силами OoO.
V>>Нужны многие десятки (сотни?) аппаратных потоков, чтобы это имело смысл.
N>Или же нужно просто не тратиться на переключение.
Дык, я именно об этом и говорю, что переключения как такового зачастую не будет, бо аппаратных потоков должно быть дохерища.
N>Например, те же регистровые блоки хитроспрятанным образом хранятся в процессоре, если он того хочет.
В кеше L0 всё, где и таблица разметки вирт.памяти.
N>Это как раз сделано в Intel VMX.
И опять это немножко не то, хоть и близко.
Понятно, что любые околопоточные вещи с хранимым контекстом потока можно притянуть за уши за аналогию, но ключевое не это, а способ запуска-останова аппаратных потоков.
N>Супервизор говорит VMLAUNCH и появляется состояние, когда завершается — зовёт VMCLEAR.
Да, программно в том числе, конечно, но больше интересует по аппаратным барьерам, например, как необходимо сводить рабочие потоки при распараллеливании циклов.
А этот барьер — просто ячейка памяти в L0, которую уменьшает счетчик, их динамически-выделяемых должно уметь создаваться немеряно для прикладных целей, сколько хатит некоей свободной для приложений памяти в L0.
N>Процессор может хранить состояния разных VM, что сейчас неактивны, а может не хранить. (Думаю, большинство текущих не хранят
Именно так.
Потоков как неких хранимых и готовых для запуска "контекстов исполнения" должно быть намного больше, чем хватает выч.блоков для одновременного их исполнения.
Плюс необходим аппаратный форк, да еще с коэф. большим 2-х — вот тебе бесплатное распараллеливание задачи навроде умножения матриц, а то сейчас само создание потоков относительно дорого.
N>Вот в это я как-то больше верю. Но смущают 1) объём этих регистровых файлов (реальный), 2) сложность переключения при OoO.
OoO — это автомат без памяти о прошлом.
Он банально на каждом шаге сортирует независимые (если они независимые) операции по времени их ожидаемой готовности к исполнению.
N>С остановкой конвейера оно понятно
ИМХО, не получится организовать такие же выч. конвейеры как в нынешних суперскалярах в такой архитектуре, придётся разбить на конвейер декодера-предзагрузчика потока (как часть области памяти контекста, при вытеснении потока в обычную память, что делает ОС при оперировании ресурсами, конвейер сбрасывается), и конвейеры векторных инструкций, привязанные к самим выч.автоматам, и там без вариантов — надо дождаться отработки многотактовой векторной инструкции, чтобы снимать поток. А некие выч.блоки не требуют личного конвейера, типа АЛУ простых арифметических и логических операций, бо такие операции однотактные и даже можно кучу таких операций за такт в одном потоке силами OoO.