The OpenNET Project / Index page

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



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

Оглавление

Релиз ядра Linux 6.5, opennews (?), 28-Авг-23, (0) [смотреть все]

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


179. "Релиз ядра Linux 6.5"  –3 +/
Сообщение от Аноним (187), 28-Авг-23, 23:27 
> Векторные инструкции производят операции над векторами (одномерными массивами) данных.
> Например, инструкция может разом сложить (умножить и т.д.) четыре числа двойной
> точности из одного 256-битного регистра с четырьмя числами двойной точности в
> другом 256-битном регистре.

Самое интересное что кому сильно хотелось что-то такое даже и в "обычных" регистрах делали. Это называется SWAR и таки иногда позволяет весьма эффективные параллельные вычисления за 1 такт даже там где "настоящий" SIMD и не ночевал, симдшники лишь сделали это удобнее и производительнее, отрастив широкие регистры с явными lanes. К сожалению это не халява - сохранять при переключении контекста пачку здоровенных регистров ну вот вообще совсем не бесплатная операция получается. Апликушникам то похрен - а в ядре где то IRQ, то задачу переключить, как раз самый экшн. И самый головняк от вон того.

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

Так можно было даже без всяких simd регистров. И кому надо этим пользовались лет так дохрена, поздравляю с прозрением.

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

А в чем разница на уровне ассемблерного кода который компилер генерит? Ему какая-то большая разница есть?

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

211. "Релиз ядра Linux 6.5"  +/
Сообщение от voiceofreason (?), 29-Авг-23, 10:45 
> весьма эффективные параллельные вычисления за 1 такт даже там где "настоящий" SIMD и не ночевал

Через libastral что-ли? Обычные инструкции будут жевать данные кусками по 64 бита с кучей приседаний, там где simd одним действием прожуёт 256 и более.

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

261. "Релиз ядра Linux 6.5"  +/
Сообщение от Аноним (261), 30-Авг-23, 01:20 
> Через libastral что-ли? Обычные инструкции будут жевать данные кусками по 64 бита

Внезапно можно рассмотреть 64 бита как 8 параллельных lanes по 8 bit. Или 4 по 16. И смолотить за 1 такт 8 одинаковых операций над u8, или 4 над u16 за присест. На базе этого внезапно есть довольно эффективные алгоритмы. Собственно, когда это началось и пришло понимание что сделать регистр вообще битов так 256-512 может быть и еще интереснее. Вон то имеет определенные плюсы: эти регистры проца всяко сохранять, и допущений минимум. А симдшные контекст очень отращивают.

Если хочется посмотреть как сие бывает, поискать по слову SWAR и будет вам SIMD без simd-регистров.

> с кучей приседаний, там где simd одним действием прожуёт 256 и более.

Приседаний там примерно столько же - идея та же самая. Просто чуть менее удобно т.к. вон там в simd регистрах - lanes могут быть и не снабжены carry в соседний lane в принудиловку. Но многие алгоритмы "для обычных регистров" просто обходят это дело - не делая математику ведущую к carry в другой lane. Просто чуть менее удобно и код специфичненько выглядит. Simd всего лишь возвел эту идею на следующий уровень, расщирив и добавив регистры и сделав lanes независимыми.

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

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

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




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

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