Информация об изменениях

Сообщение Re[7]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 20.05.2025 3:25

Изменено 20.05.2025 3:26 vdimas

Re[7]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, Sinclair, Вы писали:

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


K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом.

S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков, а мы со своими 90 впихнём столько же?

Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет.
У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)


S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше.


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


S>Хоть одним глазком — на что там Бабаяну выделили деньги.


Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".

Просто Бабаян был когда-то впечатлён Burroughs:

Сам подход к проектированию B5000 считался довольно новаторским для своего времени: обычно инженеры сначала разрабатывали аппаратную архитектуру ЭВМ, а потом предоставляли соответствующую документацию разработчикам ПО, чтобы они написали под эту архитектуру софт. В Burroughs поступили в точности наоборот: сначала подготовили требования к программному обеспечению и языкам программирования, а уже затем начали создавать под них «железо».


Рискну предположить, что увидим нечто подобное. ))
Re[7]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, Sinclair, Вы писали:

K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом.

S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков, а мы со своими 90 впихнём столько же?

Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет.
У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)


S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше.


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


S>Хоть одним глазком — на что там Бабаяну выделили деньги.


Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".

Просто Бабаян был когда-то впечатлён Burroughs:

Сам подход к проектированию B5000 считался довольно новаторским для своего времени: обычно инженеры сначала разрабатывали аппаратную архитектуру ЭВМ, а потом предоставляли соответствующую документацию разработчикам ПО, чтобы они написали под эту архитектуру софт. В Burroughs поступили в точности наоборот: сначала подготовили требования к программному обеспечению и языкам программирования, а уже затем начали создавать под них «железо».


Рискну предположить, что увидим нечто подобное. ))