The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux 6.2 войдёт подсистема для ускорителей вычислений, opennews (??), 01-Дек-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


10. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +3 +/
Сообщение от Аноним (-), 02-Дек-22, 01:01 
Чудак, чтобы RISCV инструкции как-то попали в тот блок, который где-то сбоку от основного системного проца, кто-то должен туда этот код послать.

Более того, кто-то должен отправить входные данные и забрать результат счета. И вот это вот - примерно то как современные GPU работают. По части вычислений. И там есть всякие интересные моменты, типа пересылки данных, синхронизации, очередей, статусов выполнения, все такое.

И тут оказалось что 90% этого уже было из-за современных GPU, работают они так.

Ответить | Правка | Наверх | Cообщить модератору

20. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  –2 +/
Сообщение от Аноним (20), 02-Дек-22, 04:40 
Мне давно было очевидно, что gpu это глупая идея. Инициативы по замене gpu/npu ядер процессорными симдами здорового человека очень радует, в случае успеха типовая пекарня будет не 8 cpu ядер + 72 CU, а 80 унифированных ядер.
Ответить | Правка | Наверх | Cообщить модератору

26. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +2 +/
Сообщение от Бывалый смузихлёб (?), 02-Дек-22, 07:23 
> в случае успеха типовая пекарня будет не 8 cpu ядер + 72 CU, а 80 унифированных ядер

Только в случае видеокарт под вычислительным блоком обычно подразумевается не аналог конечного ядра ЦП, а целый блок, в котором собрана пачка маломощных ядер и кое-что ещё

Едва ли удастся из десятка низкочастотных и медленных ядер сделать одно но высокочастотное и производительное для однопотока

Ответить | Правка | Наверх | Cообщить модератору

41. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (8), 02-Дек-22, 10:38 
Да нет там никакого десятка медленных ядер.
Частота у rx6000 серии около 2ггц, у серверных процессоров с десятками ядер примерно такая же. Апнуть конвейер и будет аналог серверного проца, только с большим числом регистров и более жирными кэшами.
https://images.anandtech.com/doci/4455/GCN-CU.png
Ответить | Правка | Наверх | Cообщить модератору

67. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +2 +/
Сообщение от Аноним (-), 02-Дек-22, 19:25 
> Да нет там никакого десятка медленных ядер.

Есть. Compute Unit (CU) это целая группа ALU где некоторые блоки выделены по 1 на группу, т.к. для каждой мелочевки по такому блоку было бы слишком шикарно и транжирило бы площадь кристалла.

Поэтому оно за 1 такт может сильно больше операций чем системный проц. Но с весьма большими оговорками относительно характера операций и размещения данных.

Ответить | Правка | Наверх | Cообщить модератору

34. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +1 +/
Сообщение от Аноним (-), 02-Дек-22, 08:10 
В какой-то момент fixed function hardware наворачивать всех задолбало и они вместо этого поставили массив SIMD-образных ALUшек который может что угодно считать, включая и все функции предшественников. Сначала делили шейдеры по типам, потом плюнули и сделали унифицированый массив который динамически делится по мере надобности. ALU не очень высокочастотные и не особо быстро разворачиваются в другую сторону, но их много, поэтому суммарная вычислительная мощь, если удалось распараллелить - огого.

Вон те акселераторы не так уж принципиально отличаются, просто NPU оптимизированы на другие типы данных. Им и int8 хватает, иногда еще float16 какой. Совсем базово, зато площадь ALU мизерная и их можно в чип набить, для трекинга состояния нейрона хватает. И получается ускоритель обсчета нейронов, который сразу толпу нейронов за раз ворочает. Сильно эффективнее GPU.

Типовая железка таковой врядли будет: дофига дохленьких ядер являются полным позором на не особо параллелящихся задачах и всем что "не массовые вычисления". Даже более продвинутые ALU из GPU совсем не интересны как generic процессоры. Очень медленно разворачивается в другую сторону и малоинтересен для ветвящихся/непараллелящихся/управляющих/etc задач. Это к тому что запустить 100500 процессов в параллель как бы можно но скорость их выполнения и общая эффективность будет ни о чем.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

40. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  –1 +/
Сообщение от Аноним (8), 02-Дек-22, 10:32 
>   ALU не очень высокочастотные

В CPU такие же алу, а GPU часто на том же самом кристалле с тем же самым техпроцессом.
> дофига дохленьких ядер являются полным позором

Интел унд ко не стесняются так делать уже сейчас, только в отличие от интела, тут будут простые ядра, но мощным simd. Хорошо же, хоть для той же графики использовать можно, картинки там сжимать/разжимать, скейлить, видео кодировать/декодировать, архивы паковать арифметическим кодированием. Да даже со строками чтобы работать широкие симды полезны.

Ответить | Правка | Наверх | Cообщить модератору

58. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (58), 02-Дек-22, 18:55 
> В CPU такие же алу, а GPU часто на том же самом кристалле с тем же самым техпроцессом.

Не понятно зачем тогда вообще GPU производят :). В серверных CPU видите ли это жирнючие OoO ядра со всякой спекулятивщиной и массой наворотов, оптимизирующих процессорное ядро для перфоманса на единичном потоке инструкций. По этой причине оно быстро вертится - в том числе и потому что например спекулятивно считало оба варианта бранча, просто отбросив неправильный потом. Это однако делает ядро сложным и крупным по площади. Много такого на кристалл не набьешь. Максимум несколько десятков. Зато не ударяет в грязь лицом и на единичном треде.

С другой стороны у GPU их compute units это целые группы ALUшек, где просто некоторые блоки есть по 1 штуке на группу, чтобы уменьшить оверхед: если большой сложный блок пихать каждой ALUшке, все придет к вышеупомянутому, и зачем тогда GPU вообще покупать?! Поэтому пойнт дизайна в том что более простые ALUшки гораздо более многочисленны и при правильном подходе крушат за такт неимоверное количество математических операций. Это однако имеет свою цену в виде слабого управления потоком, никакого вам OoO и проч. Так что если распараллелить не удалось, результат будет довольно жалок. Поэтому как системный проц оно такое не очень то и хотелось.

NPU это еще более жесткий вариант оптимизации где ALU еще более примитивны, иногда для минимального размера они только операции над int8 умеют. Зато их там ДОФИГА. Поэтому они за 1 присест апдейтят целый легион нейронов, показывая менее специализированным мастеркласс. В принципе на таком можно попытаться крутить крипто всякое и проч бонусом, но вот как системный процессор ЭТО будет вообще совсем ни о чем.

Ответить | Правка | Наверх | Cообщить модератору

68. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (8), 02-Дек-22, 21:53 
> Не понятно зачем тогда вообще GPU производят

Чтобы деньги зарабатывать) Продаёшь отдельно cpu + gpu + npu + vpu - юзер платит за всё - профит. А переведи тот же рендеринг видео с куцого отдельного блока с производительностью как аналогичный блок в мобилке на унифицированные ядра - это ж просто порвёт рынок, никому такое не надо, надо доить пользователя.
> Много такого на кристалл не набьешь. Максимум несколько десятков.

Core Duo e5500 - 228 млн, mac m1 ultra - 114 млрд, транзисторный бюджет ровно на тысячу вполне неплохих ядер, ну а если с какими-нибудь rsicv сравнить, счёт пойдёт на многие тысячи, и это с симдами, кэшами и конвейерами. Собственно в этом направлении сейчас и двигаются некоторые, и по маркетниговым заявлениям, уже даже попирают обычные гпухи по производительности, и на ватт, и вообще.

"ET-SoC1 (Esperanto Technologies Supercomputer-on-Chip 1, из особенностей — 1088 энергоэффективных 64-разрядных ядер RISC-V общего назначения с модулями векторных/тензорных вычислений для оптимизации и ускорения операций, которые связаны с ИИ и машинным обучением. Кроме того, чип включает четыре высокопроизводительных ядра RISC-V, 160 млн байт встроенной SRAM-памяти (152 мегабайта), плюс интерфейсы для подключения flash-памяти и внешних модулей DRAM. Насколько известно, всего в ET-SoC1 23.8 млрд транзисторов."

Ответить | Правка | Наверх | Cообщить модератору

70. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (-), 03-Дек-22, 01:48 
> Чтобы деньги зарабатывать)

А все производители суперкомпьютеров, ставящие и то и другое, наверное, лохи поголовно.

Извини, но GPU с ценой и TDP сравнимыми с моим системным процом проц кроет его в 30 раз по счету хешей. Это аргумент. И нет никакой магии разогнать системный проц в 30 раз на этой задаче. Зато на общесистемных вещах тот GPU был бы жалок. Частота ниже, exec flow control никакой, оператива оптимизирована на работу с большими блоками. А более быстрые дергания в разные стороны как системный CPU - не его это.

> - юзер платит за всё - профит.

А господа наворачивающие суперкомпьютеры при заключении миллиардных контрактов тоже калькулятором пользоваться не умеют? Да ладно?

> А переведи тот же рендеринг видео с куцого отдельного блока с производительностью
> как аналогичный блок в мобилке на унифицированные ядра - это ж просто порвёт рынок,

Вы думаете что самый умный? Ну, можете посмотреть что там LLVMPipe на практике рвет. В основном - вентилятор. При издевательском FPS'е. Ну вот хилый и прожорливый GPU из системного проца выходит.

Вообще-то как максимум умные люди допирают взять маленькое general purpose ядро, добавить SIMD туда, минимизировать площадь, и тогда если этого накопипастить побольше, довольно сносный GPU может выйти. Но вот хорошим системным процом это не станет.

Если кто не понял у системного проца и GPU довольно разные оптимизации для разных задач.

> никому такое не надо, надо доить пользователя.

Можно подумать суперкомпьютерщики не могут алгоритм допилить. Если это технически возможно. Но тут оказывается что есть задачи где надо быстро вертеться в разные стороны, с значительном перфомансом в 1 треде, а есть задачи которые можно очень массово параллелизовать. Проблема в том что это разные задачи и для этого удобны сильно разные оптимизации железа.

> Core Duo e5500 - 228 млн, mac m1 ultra - 114 млрд,
> транзисторный бюджет ровно на тысячу вполне неплохих ядер,

Просто для понимания: у немолодого GPUшки среднего ценника с скромными 20 CU - вон тех, с картинки, получится 1280 ядер с жестким тюнингом в SIMD. И это, вас не смущает что там еще неплохо бы на кеши транзисторы оставить, чем больше тем лучше, потому что если ждать DRAM на каждый пшик, вы и ARMу мобилочному продуете с треском. Потому что оператива от проца отстает очень сильно. И можно пару тыщ циклов просто ничего не делать. И толку с ваших гигагерцев, если они тысячами циклов бабмук курят ожидая пока DRAM в их сторону вообще развернется и данные даст?

> ну а если с какими-нибудь rsicv сравнить, счёт пойдёт на многие тысячи,

Ну вот минимальных RISCV в миллиарды конечно можно накопипастить, но вам очень не понравится как результат будет выглядеть на, допустим, не сильно параллелящихся задачах. Вы получите нечто типа дешевого одноплатника, с TDP и стоимостью воркстэйшна. Это, типа, огого?!

> и это с симдами, кэшами и конвейерами.

Ага, щас. Вон там видите ли у CU один несчастный блок бранчей на легион из 64 ALUшек. Как оно вертится в разные стороны при этом вы можете себе представить. Вообще совсем не так как отожраный OoO который параллельно оба направления бранча жует, отбросив неудавшийся, да еще что-нибудь префетчнув и проч, на что надо было нефигово логики к ядру донавесить.

> Собственно в этом направлении сейчас и двигаются некоторые,

Когда кто-то думает что он умнее всех остальных, он это показывает делом, имхо.

> и по маркетниговым заявлениям, уже даже попирают обычные гпухи
> по производительности, и на ватт, и вообще.

А таки специализированые акселераторы удобные под свой класс задач будут делать более общие решения по эффективности. Почему-то.

> "ET-SoC1 (Esperanto Technologies Supercomputer-on-Chip 1, из особенностей — 1088
> энергоэффективных 64-разрядных ядер RISC-V общего назначения с модулями векторных/тензорных
> вычислений для оптимизации и ускорения операций, которые связаны с ИИ и
> машинным обучением. Кроме того, чип включает четыре высокопроизводительных ядра RISC-V,

Заметьте: 4 высокопроизводительные, которые нормальные general purpose, будут координировать 1088 урезаных по максимуму вариантов. И линух будет крутиться на тех 4. А шедулить 1088 дохлых ядер ведет к дофига сохранения состояний, дикому оверхеду в шедулере и жуткому вымыванию кешей и общий результат этой активности врядли поразит воображение.

> всего в ET-SoC1 23.8 млрд транзисторов."

По поводу чего у него будет характерный размер кристалла, выход годных и ценник под стать. Вы же не думаете что кто-то себе в минус это вам продаст?

Хинт: ARM и RISCV весьма масштабируемые штуки. И если кто-то жует тот или иной набор команд, это ничего не говорит что там за "бэкэнд". Минимальный RISCV можно даже в тощий FPGA сервисным ядром втулить, что толпа народа и делает, а высокопроизводительное оптимизированое OoO ядро довольно жирное - и там совсем другие числа вентилей, но и скорость на том же потоке команд он другую кажет. Разница по жирноте ядра может быть весьма драматичной, хотя набор команд один и тот же (как минимум core). Ну и 160 мегов на 1088 ядер это так то жалкие 150 кило локального стоража на ядро. Что как бы не так уж и дофига. Не, если нейроны симулировать это с превышением. А если общесистемные задачи вертеть... ээ...

Ответить | Правка | Наверх | Cообщить модератору

72. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (72), 03-Дек-22, 13:44 
> господа наворачивающие суперкомпьютеры при заключении миллиардных контрактов

Так их вот эти миллиарды и интересуют, а не чтобы там что-то эффективно было.

> Ну вот хилый и прожорливый GPU из системного проца выходит

Так потому что ядер и алушек мало, а вот было как в Esperanto - было бы другое дело.

> 20 CU - вон тех, с картинки, получится 1280 ядер

Где вы там ядра разглядели? Нет же их, все эти алу в один неделимый блок завязаны.

Ответить | Правка | Наверх | Cообщить модератору

74. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (74), 03-Дек-22, 22:14 
> Так их вот эти миллиарды и интересуют, а не чтобы там что-то эффективно было.

Это производителя миллиарды интересуют. А клиентуру интересует как платить поменьше и получить побольше. В этом их желания расходятся. И когда клиентура почему-то вместо нвидий и интела начинает амд любить, определенные выводы напрашиваются. А таки у амд хороши что процы что GPU. И вот что что а они разные железки, совсем не конкурирующие с друг другом.

> Так потому что ядер и алушек мало,

Зато это крутые и мощные ядра, способные жевать потоки инструкций с офигенной скоростью.

> а вот было как в Esperanto - было бы другое дело.

Выглядело бы как ну хз, спарк какой-нибудь в свое время. Т.е. нечто осмысленное только на узком классе задач, кусок позора на более типовых вещах.

> Где вы там ядра разглядели? Нет же их, все эти алу в
> один неделимый блок завязаны.

Там чуть хитрее. В том смысле что эти вычисления до некоторой степени независимы. Но только до тех пор пока не потребуется что-то выбивающееся из идеи массового SIMD-процессинга. А как надо всякие продвинутости типа изменения exec flow - упс, оказыается, оно не 100% независимое, и вообще не очень то и быстро в другую сторону вертится, в отличие от вон того мегаядра.

В обычных системных задачах нечего делать такими обеъмами SIMD. Но если приспичило посчитать мультимедию, крипто, нейроны, графику, или что-то такое, оптом, вон тот дизайн получает свой пойнт, будучи в цать раз эффективнее на этих категориях задач - если было где развернуться. Это однако не значит что там офигенно системный сервис будет ворочаться. Поэтому и есть минимум два (реально уже больше) "тюнинга" существенно разных по свойствам. В системном проце SIMD весьма базовый, GPU из него состоит чуть менее чем полностью. NPU идут дальше и предпочитают легион совсем примитивных ALU - зато много. Чтобы сразу вон сколько нейронов за раз апдейтить. При этом заранеее известно что есть чем ядра занять, что потребные данные вот они, в локальном стораже, все такое. А если за эти весьма неслабые допущения вылезти все станет весьма печально. Проц общего назначения работает в совсем иных допущениях.

Ответить | Правка | Наверх | Cообщить модератору

76. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (8), 04-Дек-22, 02:22 
> И вот что что а они разные железки, совсем не конкурирующие с друг другом.

Справедливости ради GPU и под общей крышкой с CPU вполне сносные, даже на той же шине памяти. И что характерно, процессорные gflops не сильно то и отстают от встроенной видяхи.

> Зато это крутые и мощные ядра, способные жевать потоки инструкций с офигенной скоростью.

M1 гораздо на мегагерц больше делает, и при сборке одного и того же проекта ноут на интел воет турбиной, а на m1 такой холодный, что руки мёрзнут, да и активного охлаждения в принципе не предусмотрено. Что-то не вижу чтобы в связи с этим амд с интелом выбросили на помойку неэффективный x86-64 и предложили покупателям arm или risc-v.

> Выглядело бы как ну хз, спарк какой-нибудь в свое время.

Или как cell, который хоть в игровых приставках хорош был, хоть в датацентрах. Его вернуть не получится, но есть risc-v, который на гпу будет крут уже как минимум потому, что не надо будет говно на говне наворачивать типа rocm, который официально поддерживается на 2.5 неконсьюмерских видяхах не страше 3х лет.

Ответить | Правка | Наверх | Cообщить модератору

77. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (-), 04-Дек-22, 06:53 
> Справедливости ради GPU и под общей крышкой с CPU вполне сносные, даже
> на той же шине памяти.

Ну да. Шина разумеется их слабое место, которое и обеспечивает звание затычки для слота: выделенный GDDR или тем более HBM на широкой шине для графики и рядом всяко лучше.

> И что характерно, процессорные gflops не сильно то и отстают от встроенной видяхи.

А таки пойнт дизайна в том что там где надо нормальный general purpose пашет проц, а где дофига simd - GPU. А если вон то послушать не понятно зачем 2 разных блока в 1 кристалл.

> M1 гораздо на мегагерц больше делает, и при сборке одного и того
> же проекта ноут на интел воет турбиной, а на m1 такой холодный, что руки мёрзнут,
> да и активного охлаждения в принципе не предусмотрено.

У интеля перфоманс на ватт в основном маркетинговый булшит. У арма это то на чем весь их бизнес выживал. И одна из причин по которым интел не достиг успехов с "tablet PC" за много лет, вместо этого все заняли андроиды и эплы. На армах поголовно.

> Что-то не вижу чтобы в связи с этим амд с интелом выбросили на помойку
> неэффективный x86-64 и предложили покупателям arm или risc-v.

Переростки из х86-64 пока лучше получаются чем из ARM. Ну а кто там всерьез зарубится с EPYC каким? Хотя переотожраное OoO ядро разумеется имеет шансы что-то понадкусывать. И если кто не заметил вон там компании серверные чипы делают. Да, не самые топовые, но осмысленные по потреблению, недорогие, кастом для себя любимых зачастую, все такое. Потому что могут.

> Или как cell, который хоть в игровых приставках хорош был,

Он забавный но с точки зрения програминга все же брейнфак уже похожий на GPU. Но не такой массивно параллельный. И в целом пойнт этого дизайна не очень очевиден. Потому и скисло направление.

> хоть в датацентрах. Его вернуть не получится, но есть risc-v, который на гпу
> будет крут уже как минимум потому, что не надо будет говно на говне наворачивать
> типа rocm, который официально поддерживается на 2.5 неконсьюмерских видяхах не страше 3х лет.

Ну да, у амд бывают странные дергания. Но вообще наборы команд GCNов вроде добавили в GCC, а в LLVM он давно был потому что через него шейдеры в MESA генерят. Однако вот есть у вас блоб в этом коде ... и ... ? Вы же понимаете что вы не можете целиком отхапать системный GPU совсем без арбитража, очередей и проч? Для понимания что будет дальше ... любой кто с compute экспериментировал и вгружал больше чем стоило бы поймет. И там хоть какой-то планировщик все же есть, и системная графика вот совсем не отвалится, только пошаговой стратегией станет. А если целиком перехватить без инфраструктуры... это не путь многозадачной ОС.

Ответить | Правка | Наверх | Cообщить модератору

78. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (8), 04-Дек-22, 12:34 
> любой кто с compute экспериментировал и вгружал больше чем стоило бы поймет

Ну да, tensorflow на rocm бэкэнде на rx570 мало того что глючил и ломал картинку на экране во время работы, так и ещё и сливал банальному r5 3600 по скорости обучения.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

79. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (8), 04-Дек-22, 12:51 
В blender benchmark у r5 3600 и rx570 opencl кстати тоже близкие результаты получались, но у видяхи TDP кратно выше.
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

45. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (45), 02-Дек-22, 11:36 
Imtel Larabee как пример почему нифига не выйдет.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

46. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  –1 +/
Сообщение от Аноним (-), 02-Дек-22, 11:49 
> Инициативы по замене gpu/npu ядер процессорными симдами здорового человека очень радует, в случае успеха типовая пекарня будет не 8 cpu ядер + 72 CU, а 80 унифированных ядер.

CPU ограничен скоростью памяти. GPU там на каких-то мозговыносящих терабайтах в секунду данные из памяти тягает и обратно складывает, и всё за счёт того, что память заточена под нагрузку. CPU же хорош только пока все данные в кеше.

Вот когда они оперативку разгонят раз в 10-100, вот тогда GPU станет не нужным, а пока, я лучше на GPU посчитаю.

>  Мне давно было очевидно, что gpu это глупая идея.

Опеннет икспердам всё очевидно.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

47. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (20), 02-Дек-22, 12:12 
Докинут ширины шины памяти, делов-то. В мак M1 до 200 ГБ/с раскачали, у rtx 3050 224гб/с, разница невелика.
Ответить | Правка | Наверх | Cообщить модератору

66. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (-), 02-Дек-22, 19:21 
> у rtx 3050 224гб/с, разница невелика.

1) 200Гб/с для GPU уже давно не рекорд. HBM может и сильно больше.
2) Есть разница между бандвизом и латенси. Одно дело качать каждый такт широкой шины эвон какой блок, другое репрограмить все это на другой адрес, и ждать пока чипы сообразят чего от них хотят. Если так часто делать, что останется от терабайтов в секунду?

Ответить | Правка | Наверх | Cообщить модератору

73. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (73), 03-Дек-22, 16:28 
> HBM может и сильно больше.

Ну так и m1 проц для печатной машинки.

> Есть разница между бандвизом и латенси.

А кто говорил что нет? Делаешь много каналов обычной ддр5 и получаешь тот же терабайт/с что и в топовой видяхе, при этом задержка будет такой же как у обычного современного цпу. Собственно в серверных процессорах так и делают, по 8 каналов ддр, и ширина шины примерно как у видяхи выходит, но задержка меньше тк каналы независимые.

Ответить | Правка | Наверх | Cообщить модератору

75. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (75), 03-Дек-22, 22:35 
>  Ну так и 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 или что там у вас.

Ответить | Правка | Наверх | Cообщить модератору

53. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (53), 02-Дек-22, 13:40 
>CPU ограничен скоростью памяти. GPU там на каких-то мозговыносящих терабайтах в секунду данные из памяти тягает и обратно складывает, и всё за счёт того, что память заточена под нагрузку. CPU же хорош только пока все данные в кеше.

Потому что на видеокартах память припаяна рядом с процессором.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

57. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (57), 02-Дек-22, 16:14 
Не только. Она ещё заточена на то, чтоб её читать массивами. Там ж много ALU читает каждый по элементу массива, каждый из которых может быть произвольной структурой, чотатам щитает, и пишет структурку в память. Таким образом дохрена обработка масива паралельна становится. Вот память заточена под такой доступ.

Память же проца -- это RAM память, или поруски рандом акцес мемори.

Ответить | Правка | Наверх | Cообщить модератору

54. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  –2 +/
Сообщение от Ддд (?), 02-Дек-22, 13:49 
Ну давай иди посчитай хоть чтото сначала а потом перди тут)
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

60. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноним (58), 02-Дек-22, 19:02 
> CPU ограничен скоростью памяти. GPU там на каких-то мозговыносящих терабайтах в секунду

Опять же эти терабайты в основном на последовательном жирном линейном доступе, когда удалось распараллелить счет большого блока на толпу ALU и разложить данные удачно.

А если как в системном проце дергаться на всякие кучи условий во все стороны... ээ... как бы бандвиз и латенси - два разных понятия. Бандвиз там конский, но низкой латенси никто не обещал.

> того, что память заточена под нагрузку. CPU же хорош только пока
> все данные в кеше.

Да вообще-то у GPU есть и суперскоростные local storage для немедленного складирования input и output математики "локально". Чтобы не ждать черти-сколько разворота вон тех шин в правильную сторону, все заякорив. И то что там терабайты в секунду вовсе не значит что оно быстро крутанется в другую сторону когда тот код по условному бранчу передумает и решит что он хотел не то и не туда.

> Вот когда они оперативку разгонят раз в 10-100, вот тогда GPU станет
> не нужным, а пока, я лучше на GPU посчитаю.

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

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

82. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."  +/
Сообщение от Аноньимъ (ok), 13-Янв-23, 03:20 
Главное отличие не в ядрах, а в характере доступа к памяти.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру