The OpenNET Project / Index page

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



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

Оглавление

Выпуск эталонной реализации криптографической хеш-функции BLAKE3 1.0, opennews (??), 26-Июл-21, (0) [смотреть все]

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


95. "Выпуск эталонной реализации криптографической хеш-функции BL..."  +/
Сообщение от Аноним (95), 27-Июл-21, 19:25 
А почему в Сишном варианте все функции, и большие, и маленькие инлайновые? Чтобы чутка прибавить в скорости?
Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск эталонной реализации криптографической хеш-функции BL..."  +/
Сообщение от Какаянахренразница (ok), 27-Июл-21, 21:02 
inline ничего не гарантирует и ни к чему не обязывает. Как захочет компилятор.
Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск эталонной реализации криптографической хеш-функции BL..."  +/
Сообщение от Ordu (ok), 27-Июл-21, 21:21 
Инлайн может не только чутка добавить к скорости. Скажем, взять memcpy: три аргумента, с которыми функция начинает разбираться, типа выровнены указатели или невыровнены (и на какую границу -- 4 байта, 8 байт, 16 байт?), какой степени двойки кратен size, и тд и тп, после чего возможно, границы подравниваются -- происходит часть копирования невыровненным алгоритмом, потом запускается выровненный алгоритм, с максимальной пропускной способностью на остальное. Если ты вызываешь memcpy на килобайт данных, то я не удивлюсь, если эти проверки будут выполняться дольше, чем собственно копирование. (Впрочем, я не проверял, я из самых общих соображений о том, что условия ведут к сбоям конвееров, а сбои конвееров очень дорогие.)

Если memcpy заинлайнить, что часть этих проверок (а может и все проверки) компилятор сможет выполнить в процессе компиляции, может быть развернёт циклы, и де факто при копировании килобайта, ты можешь получить, что-нибудь в стиле 16 итераций цикла, в каждой из которых по 4 пересылки данных через sse, каждая из которых идёт в свой собственный конвеер, и сбой конвеера происходит ровно один раз, при завершении цикла.

Это 80-х и 90-х, когда компиляторы были тупые, инлайнить имело смысл только чтобы избежать накладных расходов на вызов функции, сегодня же, когда gcc и llvm очень глубоко анализируют код, всё стало гораздо интереснее. И это используется активно для того, и чтобы более мелко дробить код на человеку удобные куски, и чтобы писать generic (не в смысле полноценных дженериков, а в смысле на общий случай заточенные) реализации алгоритмов, которые потом оптимизатором доводятся до специально заточенной под случай реализации.

Сегодня логика такая, что чем большие куски кода ты соберёшь inline'ом в единый AST компилятору на оптимизацию, тем больше ты можешь получить бонусов от оптимизации. И поэтому, сегодня, мало уметь в ассемблер, чтобы писать быстрый код -- надо изучать свой компилятор, регулярно компилируя в асм, глядя какие оптимизации он в состоянии провести, а какие нет.

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

119. "Выпуск эталонной реализации криптографической хеш-функции BL..."  +/
Сообщение от Аноним (-), 28-Июл-21, 07:57 
> компилятор сможет выполнить в процессе компиляции, может быть развернёт циклы, и
> де факто при копировании килобайта, ты можешь получить, что-нибудь в стиле
> 16 итераций цикла, в каждой из которых по 4 пересылки данных
> через sse, каждая из которых идёт в свой собственный конвеер, и
> сбой конвеера происходит ровно один раз, при завершении цикла.

Запросто. Реально inline делает компилер более агресивным в этом самом. В других случаях он может иметь свое мнение и, например, решить что один call (или что там у вас) в несколько байтов все же прикольнее чем вооооооон те полкило кода в развороте. Инлайн хинтит ему что мы хотим скорее вот этого, даже если по другим метрикам оно вроде бы и не очень хорошо. При этом можно получить довольно дурной результат, когда вам реально раскатают огромную функцию, раз так просите. И то что оно там быстрее будет - ну, как повезет. На результат смотреть надо. У того же gcc оптимизер настолько мощный что окончательное слово за фактическим экспериментом на конкретном коде, с замером. А в разных версиях еще и разные наборы оптимизаций могут быть активны.

Какой-нибудь LTO вообще почти AI. Может выпилить половину программы, иной раз так что даже и ассемблерщик бы не допер. Он вполне просекает что срабатывают только частные случаи веток в функции, выпиливая остальные. А иногда ему что-то не нравится - и он напрочь не желает этот механизм активировать без лобового хинта inline'ом.

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

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

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




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

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