forum.opennet.ru - "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислений" (74)

"В ядро Linux 6.2 войдёт подсистема для ускорителей вычислений"

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

"В ядро Linux 6.2 войдёт подсистема для ускорителей вычислений"	+/–
Сообщение от opennews (??), 01-Дек-22, 22:29
В ветку DRM-Next, которая намечена для включения в ядро Linux 6.2, принят код новой подсистемы "accel" с реализацией фреймворка для ускорителей вычислений. Данная подсистема построена на основе DRM/KMS, поскольку разработчиками уже было произведено расщепление представления GPU на составные части, включающие в себя достаточно независимые аспекты "вывод графики" и "вычисления", так что подсистема уже могла работать с контроллерами дисплея не имеющими блока вычислений, равно как и с блоками вычислений не имеющими своего контроллера дисплея, как, например, GPU ARM Mali, который является по сути акселератором... Подробнее: https://www.opennet.me/opennews/art.shtml?num=58236
Ответить \| Правка \| Cообщить модератору

Оглавление

То есть для поддержки TPU в вёдрах больше не понадобятся гуглаговская версия ядр, Аноним (1), 22:29 , 01-Дек-22, (1)

Постепенно, вероятно, дрова желеща будут уходить на это и майнлайниться Это наз, Аноним (2), 23:02 , 01-Дек-22, (2) +9
Сделают всё в лучших традициях ещё как понадобится , Аноним (3), 23:14 , 01-Дек-22, (3)
Гугловские ускорители вообще через обычные riscv инструкции доступны без вот это, Аноним (8), 00:36 , 02-Дек-22, (8) –2

Чудак, чтобы RISCV инструкции как-то попали в тот блок, который где-то сбоку от , Аноним (-), 01:01 , 02-Дек-22, (10) +3

Мне давно было очевидно, что gpu это глупая идея Инициативы по замене gpu npu я, Аноним (20), 04:40 , 02-Дек-22, (20) –2

Только в случае видеокарт под вычислительным блоком обычно подразумевается не ан, Бывалый смузихлёб (?), 07:23 , 02-Дек-22, (26) +2

Да нет там никакого десятка медленных ядер Частота у rx6000 серии около 2ггц, у , Аноним (8), 10:38 , 02-Дек-22, (41)

Есть Compute Unit CU это целая группа ALU где некоторые блоки выделены по 1 н, Аноним (-), 19:25 , 02-Дек-22, (67) +2

В какой-то момент fixed function hardware наворачивать всех задолбало и они вмес, Аноним (-), 08:10 , 02-Дек-22, (34) +1

В CPU такие же алу, а GPU часто на том же самом кристалле с тем же самым техпроц, Аноним (8), 10:32 , 02-Дек-22, (40) –1

Не понятно зачем тогда вообще GPU производят В серверных CPU видите ли это ж, Аноним (58), 18:55 , 02-Дек-22, (58)

Чтобы деньги зарабатывать Продаёшь отдельно cpu gpu npu vpu - юзер платит, Аноним (8), 21:53 , 02-Дек-22, (68)

А все производители суперкомпьютеров, ставящие и то и другое, наверное, лохи пог, Аноним (-), 01:48 , 03-Дек-22, (70)

Так их вот эти миллиарды и интересуют, а не чтобы там что-то эффективно было Так, Аноним (72), 13:44 , 03-Дек-22, (72)

Это производителя миллиарды интересуют А клиентуру интересует как платить помен, Аноним (74), 22:14 , 03-Дек-22, (74)

Справедливости ради GPU и под общей крышкой с CPU вполне сносные, даже на той же, Аноним (8), 02:22 , 04-Дек-22, (76)
Ну да Шина разумеется их слабое место, которое и обеспечивает звание затычки дл, Аноним (-), 06:53 , 04-Дек-22, (77)
Ну да, tensorflow на rocm бэкэнде на rx570 мало того что глючил и ломал картинку, Аноним (8), 12:34 , 04-Дек-22, (78)
В blender benchmark у r5 3600 и rx570 opencl кстати тоже близкие результаты полу, Аноним (8), 12:51 , 04-Дек-22, (79)

Imtel Larabee как пример почему нифига не выйдет , Аноним (45), 11:36 , 02-Дек-22, (45)
CPU ограничен скоростью памяти GPU там на каких-то мозговыносящих терабайтах в , Аноним (-), 11:49 , 02-Дек-22, (46) –1

Докинут ширины шины памяти, делов-то В мак M1 до 200 ГБ с раскачали, у rtx 3050, Аноним (20), 12:12 , 02-Дек-22, (47)

1 200Гб с для GPU уже давно не рекорд HBM может и сильно больше 2 Есть разниц, Аноним (-), 19:21 , 02-Дек-22, (66)

Ну так и m1 проц для печатной машинки А кто говорил что нет Делаешь много кана, Аноним (73), 16:28 , 03-Дек-22, (73)

Ну так не всем суперсервер надо Особенно вон тем с батарейным питанием Вот толь, Аноним (75), 22:35 , 03-Дек-22, (75)

Потому что на видеокартах память припаяна рядом с процессором , Аноним (53), 13:40 , 02-Дек-22, (53)

Не только Она ещё заточена на то, чтоб её читать массивами Там ж много ALU чит, Аноним (57), 16:14 , 02-Дек-22, (57)

Ну давай иди посчитай хоть чтото сначала а потом перди тут , Ддд (?), 13:49 , 02-Дек-22, (54) –2
Опять же эти терабайты в основном на последовательном жирном линейном доступе, к, Аноним (58), 19:02 , 02-Дек-22, (60)

Главное отличие не в ядрах, а в характере доступа к памяти , Аноньимъ (ok), 03:20 , 13-Янв-23, (82)

Получается что можно будет обойтись без OpenCL Или OpenCL будет задействовать да, Аноним (4), 23:43 , 01-Дек-22, (4) +2

Будет всё просто по-другому, чтобы было что постоянно переписывать , Аноним (3), 23:53 , 01-Дек-22, (5) +12

А потом компилять Ждём ebuild ы , Аноним (6), 00:13 , 02-Дек-22, (6) +2

Только-только ржавый опенцл в мезу втащили, а уже выкидывать пора 128513 , Аноним (8), 00:32 , 02-Дек-22, (7) +3

Лучше сразу и выкинуть , Аноним (50), 12:28 , 02-Дек-22, (50)

Это более низкий уровень, некий базовый обмен с акселераторами и налажывание вып, Аноним (-), 01:03 , 02-Дек-22, (11) –1
без опенцл не обойтись это описание того чего надо вычислить а тут просто пра, pfg21 (ok), 01:30 , 02-Дек-22, (17)

Только бы эти аутисто ускорители желательно не затрагивали версию 20 04 и 21 04 , Аноним (9), 00:44 , 02-Дек-22, (9) –4

Узбагойтесь, ваш домашний селерончик как работал, так работать и будет , Аноним (18), 01:31 , 02-Дек-22, (18) +2

в итоге все эти дрова и обвязки для _ускорителей_ по факту будут только тормозит, Аноним (12), 01:04 , 02-Дек-22, (12) –1

Это как Вот прям ща opencl на моем GPU долбит в 30 раз больше хешей чем CPU в п, Аноним (-), 01:09 , 02-Дек-22, (14)

А в чём смысл для дома хеши вычеслят Опять майнинг А практичнее что-то кроме к, Аноним (-), 07:17 , 02-Дек-22, (23) +2

Не всмысле для дома как жилиища, а в мысле как бы точнее выразится Длоя обычног, Аноним (-), 07:20 , 02-Дек-22, (24)

Для , Аноним (-), 07:20 , 02-Дек-22, (25)

Угадать ваш пароль в 100500 раз быстрее, если хэш удалось утащить, например , Аноним (-), 08:15 , 02-Дек-22, (35) +2
Смотрите вы ваш Ютубчик Там сначала декодирование TLS, потому декодирование AV1, Аноним123 (?), 11:23 , 05-Дек-22, (80)

автор, разбивай предложения на куски 5 раз за коротенькую новость написать под, username hidden (?), 01:13 , 02-Дек-22, (15) +2

Там под новостью кнопка исправить есть Жми смело и правь как душе угодно Как, Аноним (-), 01:26 , 02-Дек-22, (16) +2

Так она без JavaScript не работает, как и плюсы-минусы , Аноним (39), 10:30 , 02-Дек-22, (39)

Прочитай код, сделай сам запрос через curl , Аноним (43), 10:47 , 02-Дек-22, (43) +1
Ну да, паскудство, что сказать Тогда придется жить с тем что есть , Аноним (74), 19:06 , 02-Дек-22, (61)

Опять в ядро тащат то, что должно быть в драйверах Синдром Плюшкина во все поля, ИмяХ (?), 06:32 , 02-Дек-22, (21) +1

А драйвере где Драйвера в ядре Или имелось ввиду сначало в драйвер производите, Аноним (-), 07:36 , 02-Дек-22, (28) +2

драйвера, Аноним (-), 07:36 , 02-Дек-22, (29)
А забыл видео карта же Я не пользуюсь в линукс драйверами для видкокарт те что , Аноним (-), 07:42 , 02-Дек-22, (30)

Вот как раз один из вариантов по чму ак не все устанавливают драйвера для видеок, Аноним (-), 07:44 , 02-Дек-22, (31)

так, Аноним (-), 07:45 , 02-Дек-22, (32)
Потому, что те, что в не в ядре - клозетсорс, а исполняться хотят в пространстве, Аноним (50), 12:38 , 02-Дек-22, (52) +1

А кто сказал, что оно не в модуле будет , Аноним (50), 12:34 , 02-Дек-22, (51)

Линь теперь определенно ось для копателей Больше гикам подработать негде, по фан, Попандопала (?), 08:28 , 02-Дек-22, (37) –3
Мне кажется, что пора делать линух гибридным хотябы как NT Засирают ядро, ей , Аноним (42), 10:45 , 02-Дек-22, (42) –2

Как Стрекозиное ядро , Аноним (50), 12:27 , 02-Дек-22, (49)
Он и так гибридный Просто API ядра нестабильное, это так специально, чтобы прои, Аноним (55), 14:03 , 02-Дек-22, (55)

Вообще-то сборку можно выбрать вкомпилить в ядро или загружаемым модулем ядра , Аноним (50), 18:59 , 02-Дек-22, (59)

Там вообще довольно много чего есть для выпихивания ряда вещей в юзерспейс Так , Аноним (74), 19:13 , 02-Дек-22, (64)

Оно модульное и к тому же конфигуряется что и как И что значит - засирают Добр, Аноним (74), 19:11 , 02-Дек-22, (63)

Ускорители вычислений Изобретите мне замедлитель времени , InuYasha (??), 10:53 , 02-Дек-22, (44) +2

Это будет лучше, чем криокамера , Аноним (50), 12:24 , 02-Дек-22, (48) +1
Изобретён давно Правда эффекта ощутимого при существующих технологиях пока нет , Аноним (55), 14:05 , 02-Дек-22, (56)
Чо, релятивизм тебе в школе не читали Где взять столько энергии и технологии дв, Аноним (74), 19:09 , 02-Дек-22, (62) –1

О, умник из Чарли и школоладная фабрика засветился Ну, читай, читай А я в а, InuYasha (??), 22:13 , 02-Дек-22, (69)

Может, ты в аспирантуре бухал а не читал Иначе знал бы что вот как раз по части, Аноним (-), 02:06 , 03-Дек-22, (71) –1

Без проблем Разгоняетесь до скорости света и наблюдаете из своей ракеты как Зем, Аноним123 (?), 11:28 , 05-Дек-22, (81)

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

1. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (1), 01-Дек-22, 22:29

То есть для поддержки TPU в вёдрах больше не понадобятся гуглаговская версия ядра?

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

2. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +9 +/–

Сообщение от Аноним (2), 01-Дек-22, 23:02

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

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

3. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (3), 01-Дек-22, 23:14

Сделают всё в лучших традициях: ещё как понадобится.

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

8. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –2 +/–

Сообщение от Аноним (8), 02-Дек-22, 00:36

Гугловские ускорители вообще через обычные riscv инструкции доступны без вот этого вот всего https://servernews.ru/1074746

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

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ообщить модератору

4. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (4), 01-Дек-22, 23:43

Получается что можно будет обойтись без OpenCL?
Или OpenCL будет задействовать данный механизм?

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

5. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +12 +/–

Сообщение от Аноним (3), 01-Дек-22, 23:53

Будет всё просто по-другому, чтобы было что постоянно переписывать.

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

6. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (6), 02-Дек-22, 00:13

А потом компилять! Ждём ebuild'ы...

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

7. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +3 +/–

Сообщение от Аноним (8), 02-Дек-22, 00:32

Только-только ржавый опенцл в мезу втащили, а уже выкидывать пора😁

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

50. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (50), 02-Дек-22, 12:28

Лучше сразу и выкинуть.

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

11. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –1 +/–

Сообщение от Аноним (-), 02-Дек-22, 01:03

Это более низкий уровень, некий базовый обмен с акселераторами и налажывание выполнения джобов на них. Откуда эти джобы берутся, какое апи вывешивается для их генерации и прочее - вне этого контекста.
GPU может озадачивать вулкан, может opengl, может compute-нагрузка при том из нескольких источников, что opencl что compute шейдеры в вулкане или opengl. Это другой аспект и реализуется другим уровнем софта.

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

17. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от pfg21 (ok), 02-Дек-22, 01:30

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

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

9. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –4 +/–

Сообщение от Аноним (9), 02-Дек-22, 00:44

Только бы эти аутисто ускорители желательно не затрагивали версию 20.04 и 21.04 потому что лучше сделать не могут.

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

18. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (18), 02-Дек-22, 01:31

Узбагойтесь, ваш домашний селерончик как работал, так работать и будет.

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

12. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –1 +/–

Сообщение от Аноним (12), 02-Дек-22, 01:04

в итоге все эти дрова и обвязки для _ускорителей_ по факту будут только тормозить ядро

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

14. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 01:09

Это как? Вот прям ща opencl на моем GPU долбит в 30 раз больше хешей чем CPU в принципе мог изобразить. Можете попробовать порвать такой результат без аскселерации, удачи.

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

23. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (-), 02-Дек-22, 07:17

А в чём смысл для дома хеши вычеслят? Опять майнинг? А практичнее что-то кроме крипты как пример есть?

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

24. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:20

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

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

25. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:20

Для.

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

35. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (-), 02-Дек-22, 08:15

> А практичнее что-то кроме крипты как пример есть?
"Угадать" ваш пароль в 100500 раз быстрее, если хэш удалось утащить, например :)

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

80. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним123 (?), 05-Дек-22, 11:23

Смотрите вы ваш Ютубчик. Там сначала декодирование TLS, потому декодирование AV1.

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

15. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от username hidden (?), 02-Дек-22, 01:13

автор, разбивай предложения на куски. 5 раз за коротенькую новость написать "подсистема" -- это жесть полная.

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

16. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (-), 02-Дек-22, 01:26

> автор, разбивай предложения на куски. 5 раз за коротенькую новость написать "подсистема"
> -- это жесть полная.
Там под новостью кнопка "исправить" есть. Жми смело и правь как душе угодно. Как модератор апрувнет так и будет по твоему. Если апрувнет, конечно, так что сильно придуряться не стоит.

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

39. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (39), 02-Дек-22, 10:30

Так она без JavaScript не работает, как и плюсы-минусы.

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

43. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +1 +/–

Сообщение от Аноним (43), 02-Дек-22, 10:47

Прочитай код, сделай сам запрос через curl.

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

61. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (74), 02-Дек-22, 19:06

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

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

21. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +1 +/–

Сообщение от ИмяХ (?), 02-Дек-22, 06:32

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

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

28. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от Аноним (-), 02-Дек-22, 07:36

А драйвере где? Драйвера в ядре. Или имелось ввиду сначало в драйвер производитель чипа помещает, а потом в ядро драйвер размещают? Так имелось ввиду?

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

29. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:36

драйвера

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

30. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:42

А забыл видео карта же. Я не пользуюсь в линукс драйверами для видкокарт те что не в ядре а отдельно.

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

31. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:44

Вот как раз один из вариантов по чму ак не все устанавливают драйвера для видеокарты, а используют драйвера те что в ядре уже есть.

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

32. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (-), 02-Дек-22, 07:45

так

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

52. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +1 +/–

Сообщение от Аноним (50), 02-Дек-22, 12:38

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

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

51. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (50), 02-Дек-22, 12:34

А кто сказал, что оно не в модуле будет?

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

37. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –3 +/–

Сообщение от Попандопала (?), 02-Дек-22, 08:28

Линь теперь определенно ось для копателей.Больше гикам подработать негде, по фану, не нужно программируют толпами. Бесполезники.D

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

42. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –2 +/–

Сообщение от Аноним (42), 02-Дек-22, 10:45

Мне кажется, что пора делать линух гибридным (хотябы как NT). Засирают ядро, ей богу...

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

49. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (50), 02-Дек-22, 12:27

Как Стрекозиное ядро.

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

55. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (55), 02-Дек-22, 14:03

Он и так гибридный. Просто API ядра нестабильное, это так специально, чтобы производители либо драйвера открывали, либо сами их и поддерживали, либо не делали и не поддерживали вовсе (самый приемлимый для производителя вариант).

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

59. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (50), 02-Дек-22, 18:59

Вообще-то сборку можно выбрать: вкомпилить в ядро или загружаемым модулем ядра. Но нельзя в каком-то виде для исполнения в отдельном адресном пространстве.

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

64. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (74), 02-Дек-22, 19:13

> Вообще-то сборку можно выбрать: вкомпилить в ядро или загружаемым модулем ядра. Но
> нельзя в каком-то виде для исполнения в отдельном адресном пространстве.
Там вообще довольно много чего есть для выпихивания ряда вещей в юзерспейс. Так что кому оно надо - это уже давно практикует. А то что не очень популярно - простите, парни, оверхед от переключения контекста между кернелом и юзером никуда не пропадет, чудес не бывает. Его минимизировали насколько могли, в том числе рядом весьма хитрых трюков, но полной халявой это не станет.

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

63. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (74), 02-Дек-22, 19:11

> Мне кажется, что пора делать линух гибридным (хотябы как NT). Засирают ядро,
> ей богу...
Оно модульное и к тому же конфигуряется что и как. И что значит - засирают? Добрых 90% этого и так уже было и использовалось GPUшками. Просто не понятно почему это счастье должно быть доступно только им когда NPU какие-нибудь тоже с удовольствием бы той инфраструктурой пользовались.

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

44. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +2 +/–

Сообщение от InuYasha (??), 02-Дек-22, 10:53

Ускорители вычислений... Изобретите мне замедлитель времени!

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

48. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +1 +/–

Сообщение от Аноним (50), 02-Дек-22, 12:24

Это будет лучше, чем криокамера :)

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

56. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним (55), 02-Дек-22, 14:05

Изобретён давно. Правда эффекта ощутимого при существующих технологиях пока нет.

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

62. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –1 +/–

Сообщение от Аноним (74), 02-Дек-22, 19:09

> Ускорители вычислений... Изобретите мне замедлитель времени!
Чо, релятивизм тебе в школе не читали? Где взять столько энергии и технологии двигателей ты сам как-нибудь придумай. Да и как это работает тебе не факт что понравится.

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

69. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от InuYasha (??), 02-Дек-22, 22:13

О, умник из "Чарли и школоладная фабрика" засветился ) Ну, читай, читай. А я в аспирантуре читал что релятивизм - это всего лишь общепринятая гипотеза. Теория, в лучшем случае.

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

71. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." –1 +/–

Сообщение от Аноним (-), 03-Дек-22, 02:06

Может, ты в аспирантуре бухал а не читал? Иначе знал бы что вот как раз по части времени релятивизм недурно подтвержден, допустим, спутниками навигационных систем. Которые бы дико гнали в координатах из-за только подумайте, того факта что их время течет иначе чем на Земле. Вот прямо так. Что хотите с этим фактом то и делайте, но на спутниках атомные часы, это позволяет довольно точно померять то что там творится с временем, более того, компенсация этого для приведения к земному времени абсолютно необходимое условие для какой-то разумной точности позиционирования - свет очень быстрая штука, ошибка в секунду это 3*10^8 метров ошибки дистанции. И вот тут приходится учитывать все мыслимые эффекты. Релятивизм один из топовых аспектов коррекции.

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

81. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..." +/–

Сообщение от Аноним123 (?), 05-Дек-22, 11:28

Без проблем. Разгоняетесь до скорости света и наблюдаете из своей ракеты как Земля умирает от старости.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."	+/–
Сообщение от Аноним (1), 01-Дек-22, 22:29
То есть для поддержки TPU в вёдрах больше не понадобятся гуглаговская версия ядра?
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."	+9 +/–
	Сообщение от Аноним (2), 01-Дек-22, 23:02
	Постепенно, вероятно, дрова желеща будут уходить на это и майнлайниться. Это назревало давно, поскольку многие GPU на самом деле давно уже стали акселераторами вычислений и даже видеовыход не у всех уже есть, датацентровым числодроиблкам на основе амд и нвидий выход на экран не очень то и нужен был уже давно. А тут доразвили немного идею, давно напрашивалось и вот наконец сделали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."	+/–
	Сообщение от Аноним (3), 01-Дек-22, 23:14
	Сделают всё в лучших традициях: ещё как понадобится.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	8. "В ядро Linux 6.2 войдёт подсистема для ускорителей вычислени..."	–2 +/–
	Сообщение от Аноним (8), 02-Дек-22, 00:36
	Гугловские ускорители вообще через обычные riscv инструкции доступны без вот этого вот всего https://servernews.ru/1074746
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	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ообщить модератору