Re[31]: Эльбрус мёртв, да здравствует Эльбрус-Б!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.25 05:42
Оценка:
Здравствуйте, vdimas, Вы писали:

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

V>>>Дык, а как сейчас останавливают и запускают логические потоки? — программно.
V>>>Но я не вижу проблем перенести в железо львиную долю этой логики.
N>>Уже было в 80286. Почему-то к тем "таскам" возвращаться не хотят.
V>Не тот уровень решения проблемы.
V>Нужны многие десятки (сотни?) аппаратных потоков, чтобы это имело смысл.

Или же нужно просто не тратиться на переключение.
Например, те же регистровые блоки хитроспрятанным образом хранятся в процессоре, если он того хочет.
Это как раз сделано в Intel VMX. Супервизор говорит VMLAUNCH и появляется состояние, когда завершается — зовёт VMCLEAR. Процессор может хранить состояния разных VM, что сейчас неактивны, а может не хранить. (Думаю, большинство текущих не хранят

Вот в это я как-то больше верю. Но смущают 1) объём этих регистровых файлов (реальный), 2) сложность переключения при OoO. С остановкой конвейера оно понятно, а без остановки — добавляется ещё один уровень сложности к тому, что имеем.
При параллельной работе — ещё больше.

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

V>>>А он де-факто уже есть даже в мейнстримовых архитектурах на уровне кеша 0-го уровня — в этом банке хранятся как "реальные" регистры, куда ОоО совершает отображение-переименование,
N>>Там редко когда аппаратных регистров больше в 10 раз чем архитектурных.
V>А и не будет больше это отношение.
V>И там не в 10 раз, а поменьше, вроде.

Ой сомневаюсь. Я не видел цифр собственно регистров, но при 97 команд уровня ISA и 224 микрооперациях, которые в пределе могут лежать в конвейере (Skylake и пара ближайших за ним поколений), 10 это даже мало.

V>Просто будет больше самих наборов регистров, т.к. будет больше аппаратных потоков.


Чтобы таки одну нить разогнать, надо много регистров.

V>>> так и таблицы разметки виртуальной памяти.

N>>Кэш совсем не резиновый, а тегирование через PCID эффективно работает максимум на 1 процесс назад. По сути от того идентификатора остаётся только упрощение для ОС.
V>Это схема показала себя де-факто плохой.
V>Переключение контекстов дорого в основном из-за "разогрева" таблиц виртуальной памяти.
V>НизачОт современному мейнстриму, кароч. ))

Так PCID как раз для сокращения разогрева и нужен.
А если все харты раздельно работают, то зачем им общий кэш трансляций?

V>И да, много потоков в одном процессе — это не то же самое, что много независимых процессов, т.е. потоки одного процесса шарят контекст исполнения.


Как раз на уровне написания кода чем меньше они будут шарить — тем лучше.

V>>> Просто требуется этот подход тоже довести до абсурда банально через экстенсивное увеличение размера кеша 0-го уровня и снабдив его огромной ассоциативной схемой отображения,

N>>Как ты думаешь, почему L1 кэши памяти такие маленькие?
V>Потому что сложная ассоциативная схема отображения на память — ведь отображение происходит на произвольную память.
V>А для L0 эта схема очень простая — каждый поток имеет свой участок в кеше L0, т.е. "отображение" с большой вероятностью будет заключаться в старших битах адреса обращения к этому кешу, где значения этих бит константны для каждого потока. Динамическое отображение потребуется только для OoO и спекулятивного исполнения. И то... Возможно будет "дешевле" просто взять статической памяти с запасом, чем наверчивать динамическое аппаратное распределение этой памяти. ))

Разъясни подробнее, если можешь.

V>>>И я уже видел не раз эти схемы ранее (не связанные конкретно с Эльбрус-Б) и почитывал обсуждения способов решения проблематики.

V>>>Они не изобретают чего-то нового — попытки реализации в железе (но совсем на другом уровне в прошлые десятилетия) уже были.
N>>"Попытки", угу.
V>Ну так и векторные процессоры были уже в 70-е, но выстрелили только в конце 90-х в первых 3D-видюхах, когда кол-во АЛУ взяли на порядок больше.
V>Т.е., количество иногда переходит совсем в новое качество. ))

Если бы то, что ты говоришь, было верным, MMX и SSE появились бы или лет на 15 раньше, или на 10 позже. Но они появились до массовых GPGPU.

V>>>С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда",

N>>Кавычки явно лишние.
V>))
V>Да не, у них на хорошем уровне получилось, не как у бедноватых сигнальных процов.

То-то до сих пор нет ни одного авторитетного независимого обзора. "И вы говорите" (ц).

V>Но это потому что ниша стоимости у проца другая, смог себе позволить.


И не могли себе позволить SRAM с сильно меньшими и более однородными(!) таймингами — за все мегатонны нефти?
Ой не верится.
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.