Сообщение Re[7]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 20.05.2025 3:25
Изменено 20.05.2025 3:26 vdimas
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 поступили в точности наоборот: сначала подготовили требования к программному обеспечению и языкам программирования, а уже затем начали создавать под них «железо».
Рискну предположить, что увидим нечто подобное. ))
K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом.
S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков, а мы со своими 90 впихнём столько же?
Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет.
У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)
S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше.
Основная проблема многоядерников — это когерентность памяти.
Сейчас обеспечение этой когерентности безальтернативное и довольно-таки тупое — по линейкам кеша, но оно зачастую оно не требуется вовсе, а ср-в управления когерентностью нет.
Т.е. лишние тормоза зачастую, возня с физическим разнесением конкурентно обрабатываемых независимых данных по линейкам этого кеша и прочие постыдные для 21-го века танцы с бубном, которые исполняет программист, а не компилятор + железо.
S>Хоть одним глазком — на что там Бабаяну выделили деньги.
Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".
Просто Бабаян был когда-то впечатлён Burroughs:
Сам подход к проектированию B5000 считался довольно новаторским для своего времени: обычно инженеры сначала разрабатывали аппаратную архитектуру ЭВМ, а потом предоставляли соответствующую документацию разработчикам ПО, чтобы они написали под эту архитектуру софт. В Burroughs поступили в точности наоборот: сначала подготовили требования к программному обеспечению и языкам программирования, а уже затем начали создавать под них «железо».
Рискну предположить, что увидим нечто подобное. ))