Исходное сообщение
"Выпуск эталонной реализации криптографической хеш-функции BL..." Отправлено Ordu, 27-Июл-21 21:21
Инлайн может не только чутка добавить к скорости. Скажем, взять memcpy: три аргумента, с которыми функция начинает разбираться, типа выровнены указатели или невыровнены (и на какую границу -- 4 байта, 8 байт, 16 байт?), какой степени двойки кратен size, и тд и тп, после чего возможно, границы подравниваются -- происходит часть копирования невыровненным алгоритмом, потом запускается выровненный алгоритм, с максимальной пропускной способностью на остальное. Если ты вызываешь memcpy на килобайт данных, то я не удивлюсь, если эти проверки будут выполняться дольше, чем собственно копирование. (Впрочем, я не проверял, я из самых общих соображений о том, что условия ведут к сбоям конвееров, а сбои конвееров очень дорогие.) Если memcpy заинлайнить, что часть этих проверок (а может и все проверки) компилятор сможет выполнить в процессе компиляции, может быть развернёт циклы, и де факто при копировании килобайта, ты можешь получить, что-нибудь в стиле 16 итераций цикла, в каждой из которых по 4 пересылки данных через sse, каждая из которых идёт в свой собственный конвеер, и сбой конвеера происходит ровно один раз, при завершении цикла. Это 80-х и 90-х, когда компиляторы были тупые, инлайнить имело смысл только чтобы избежать накладных расходов на вызов функции, сегодня же, когда gcc и llvm очень глубоко анализируют код, всё стало гораздо интереснее. И это используется активно для того, и чтобы более мелко дробить код на человеку удобные куски, и чтобы писать generic (не в смысле полноценных дженериков, а в смысле на общий случай заточенные) реализации алгоритмов, которые потом оптимизатором доводятся до специально заточенной под случай реализации. Сегодня логика такая, что чем большие куски кода ты соберёшь inline'ом в единый AST компилятору на оптимизацию, тем больше ты можешь получить бонусов от оптимизации. И поэтому, сегодня, мало уметь в ассемблер, чтобы писать быстрый код -- надо изучать свой компилятор, регулярно компилируя в асм, глядя какие оптимизации он в состоянии провести, а какие нет.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Инлайн может не только чутка добавить к скорости. Скажем, взять memcpy: три > аргумента, с которыми функция начинает разбираться, типа выровнены указатели или невыровнены > (и на какую границу -- 4 байта, 8 байт, 16 байт?), > какой степени двойки кратен size, и тд и тп, после чего > возможно, границы подравниваются -- происходит часть копирования невыровненным алгоритмом, > потом запускается выровненный алгоритм, с максимальной пропускной способностью на остальное. > Если ты вызываешь memcpy на килобайт данных, то я не удивлюсь, > если эти проверки будут выполняться дольше, чем собственно копирование. (Впрочем, я > не проверял, я из самых общих соображений о том, что условия > ведут к сбоям конвееров, а сбои конвееров очень дорогие.) > Если memcpy заинлайнить, что часть этих проверок (а может и все проверки) > компилятор сможет выполнить в процессе компиляции, может быть развернёт циклы, и > де факто при копировании килобайта, ты можешь получить, что-нибудь в стиле > 16 итераций цикла, в каждой из которых по 4 пересылки данных > через sse, каждая из которых идёт в свой собственный конвеер, и > сбой конвеера происходит ровно один раз, при завершении цикла. > Это 80-х и 90-х, когда компиляторы были тупые, инлайнить имело смысл только > чтобы избежать накладных расходов на вызов функции, сегодня же, когда gcc > и llvm очень глубоко анализируют код, всё стало гораздо интереснее. И > это используется активно для того, и чтобы более мелко дробить код > на человеку удобные куски, и чтобы писать generic (не в смысле > полноценных дженериков, а в смысле на общий случай заточенные) реализации алгоритмов, > которые потом оптимизатором доводятся до специально заточенной под случай реализации. > Сегодня логика такая, что чем большие куски кода ты соберёшь inline'ом в > единый AST компилятору на оптимизацию, тем больше ты можешь получить бонусов > от оптимизации. И поэтому, сегодня, мало уметь в ассемблер, чтобы писать > быстрый код -- надо изучать свой компилятор, регулярно компилируя в асм, > глядя какие оптимизации он в состоянии провести, а какие нет.
	Введите код, изображенный на картинке: