The OpenNET Project / Index page

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



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

Оглавление

Первый стабильный выпуск zlib-ng, высокопроизводительного форка zlib , opennews (??), 17-Мрт-21, (0) [смотреть все] +1

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


116. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/
Сообщение от Аноним (116), 18-Мрт-21, 03:36 
>Добиться существенного повышения производительности сжатия/распаковки в основном удалось благодаря задействованию векторных инструкций SSE*, AVX2, VSX и Neon.

Неужели в GCC автовекторизатор на -O3 работает настолько плохо?

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

146. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/
Сообщение от uis (ok), 18-Мрт-21, 11:13 
> Неужели в GCC автовекторизатор на -O3 работает настолько плохо?

Обычно хуже, чем ручками

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

166. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/
Сообщение от пох. (?), 18-Мрт-21, 17:14 
он вообще никак не работает. Что бы там секта свидетелей -O9 не бормотала. Собственно, он даже в прекрасном icc не работает.

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

Поэтому проще сразу написать на ассемблере - его знание тебе все равно понадобится.

Единственный бонус от писания под "автовекторизаторы" - такой код худо-бедно компилируется везде, не требуя пресловутых ifdef и стремных тестов по автоугадаву наличных фич компилятора. Но работает плохо.

Но одновременно avx2/sse и neon - это все равно фантастика, ненаучная.

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

204. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/
Сообщение от Аноним (204), 19-Мрт-21, 02:37 
> Поэтому проще сразу написать на ассемблере

Есть ещё промежуточный вариант - интринсики. Чуть удобнее ассемблера.

> его знание тебе все равно понадобится.

Это да.

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

219. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/
Сообщение от пох. (?), 19-Мрт-21, 08:41 
> Есть ещё промежуточный вариант - интринсики. Чуть удобнее ассемблера.

теперь тебе надо не только знать ассемблер и архитектуру (три разных, как в этом проекте), но еще и замысловатый синтаксис конкретного компилятора ;-)

Фиг знает, удобнее или нет - я так и не осилил, каждый раз матерюсь, натыкаясь в чужом коде.
Как по мне - asm {} были удобочитаемей. Правда, регистры надо сохранять самому.

Причем от необходимости проверять, умеет ли данная связка конкретной версии gcc и конкретной версии gas конкретно твой avx2 ни разу не избавляет.

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

232. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/
Сообщение от Аноним (204), 19-Мрт-21, 12:50 
? Наоборот же. Интринсики описываются в .h файле и имеют тот же самый С-интерфейс для каждого компилятора, который их поддерживает. А синтаксис блока asm {} и его взаимодействия с остальным С-кодом как раз любит чуть-чуть отличаться от компилятора к компилятору.
Ответить | Правка | Наверх | Cообщить модератору

279. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/
Сообщение от Аноним (-), 27-Мрт-21, 01:24 
> теперь тебе надо не только знать ассемблер и архитектуру (три разных, как
> в этом проекте), но еще и замысловатый синтаксис конкретного компилятора ;-)

Немного не так. Теперь надо знать "возможности архитектуры" и "желаемую операцию". При этом есть шанс что на разных платформах смогут относительно эффективно скроить вон то (интринсик с этим синтаксисом) из того что у платформы есть.

Если что я таки запиливал интринсики себе, "как у ARM и STM32 в cmsis, но моим кодом с моей лицензией" (а почему бы и нет?!). Т.е. некий "compat".

Caller однако понятия не имеет что там унутрях __disable_irq() какого. И, более того, это сработает и на ARM и на RISCV, если я (или кто-то еще) запилит это __disable_irq() в тамошних абастракциях. Внутрях ARM и RISCV конечно разные, но caller эту разницу не увидит.

С математикой ессно сложнее - часто фичи того или иного набора команд достаточно уникальны и не имеют прямых аналогов. Сэмулировать можно что угодно, но если это не ускоряет операцию, смысл теряется и зачем такой интринсик надо? Он на раз окажется хуже сишного кода :)

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

Ну вот у именно x86 с их адовым количеством команд - так себе развлекуха. Я интринсики чуть по другому поводу научился.

> Как по мне - asm {} были удобочитаемей. Правда, регистры надо сохранять самому.

Технически интринсики и есть в общем то это самое, просто делается не тобой а ты уже готовое дергаешь, и по задумке сие может быть сделано под разные платформы/компилеры. В чем пойнт? В том что код при миграции менять не надо в идеале. Это головняк system implementer'а, тулчейна, либы, или кого-то еще, но не вон того прогера, который просто дергает фичу.

> Причем от необходимости проверять, умеет ли данная связка конкретной версии gcc и
> конкретной версии gas конкретно твой avx2 ни разу не избавляет.

Ну, вообще, если хочешь вы...ся можешь попробовать incbin :D :D прекомпильнутого блоба :))) делать из асма, при этом его понимание набора команд до лампочки. Но за такую реализацию интринсика желающие тебя линчевать выстроятся в очередь...

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

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

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




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

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