> Ну так и m1 проц для печатной машинки.Ну так не всем суперсервер надо. Особенно вон тем с батарейным питанием.
> А кто говорил что нет? Делаешь много каналов обычной ддр5 и получаешь
> тот же терабайт/с что и в топовой видяхе,
Вот только HBM на видяхе - 4096-битная (!!!) шина, чтоли. Можешь себе представить сколько оно за такт толкает одним блоком. Но есть нюансы.
1) На FR4 такое раскидать малореально. Поэтому там извините GPU и HBM на _кремниевом_ интерпозере чтобы столько линий вообще пробросить. Это делает технологию весьма дорогой и нишевой.
2) Даже если вы протолкали вон столько за раз - это ничего не говорит о том сколько времени надо чтобы развернуть ЭТО в другой адрес. Поэтому оно круто, когда 1 раз зарядили адрес и дальше вон теми блоками оптом гребут. В случае графики и вычислений пригодных для GPU оно так и будет. А если там попробовать резко вертеться в разные стороны - фигня получится, дорогущее железо будет работать хуже чем копеечное general purpose.
Вон тот дизайн оптимизирован на массовый SIMD и специфичный стиль счета. Что по структуре блоков выполнения, что по структуре памяти. Если подсунуть не это - фигня получается, оптиимизации в обратную сторону икаются.
Да, кстати, амд так то упаковывает CPU + GPU в 1 кристалл. Казалось бы - проще унифицированых ядер набить побольше. Ан нет. Так это будет паршивый CPU и паршивый GPU. Кому такое надо?!
> при этом задержка будет такой же как у обычного современного цпу.
Это в допущении что вы такое число линий по FR4 в принципе раскидать способны. Даже если это получится, расстояния будут другие, технологические нормы производства печаток улетят в небеса, с какой итерации платы этот монстр вообще заработает - черт знает (выравнивать кучу линий так себе веселье), слоев будет дохрена, ну и в целом это будет очень дорогая и очень нишевая штука. Поэтому и не захватит мир. А так топовых серверов с несколькими процами и каналами памяти - есть. Но даже если там графика и заведется с сравнимым с средним GPU перфомансом, это другое потребление и стоимость.
> Собственно в серверных процессорах так и делают, по 8 каналов ддр, и ширина шины
> примерно как у видяхи выходит, но задержка меньше тк каналы независимые.
Задержка не зависит от числа каналов. Если префетч не угадал что мы хотим после адреса 0x100500 совсем другой адрес 0xABCDEF10 - то уж не угадал и баста. Если то что там лежит надо для дальнейших вычислений, окей, значит все что зависело от этого доступа встает на паузу, одно ядро или 101, какая разница, они скипают свои циклы зафиг. А там пока по шине в чипы новый адрес уедет, пока они одуплят и подготовят данные, пока это начнет взад лететь...
...если кто не понял: крупноблочный последовательный доступ выигрывает только если доступ реально линейный и много. А если это рандомные дерги... и куча мелких ядер конкурирующих за кеш будут жестко его вымывать, в результате большая их часть может начать туповэйтить доступов по шинам, потому что общими усилиями кэш вынесли. В случае GPU и вычислительных нагрузок бывает более плотный и явный контроль над local storage, но это весьма специфичный вид вычислений. Далекий от того как оно на системных процах. Ну вот не работает так условный httpd или что там у вас.
