IJ
Кроме того в зависимости от процессора новые блестящие векторные инструкции могут работать быстрее или не быстрее старых, т.к. грубо говоря есть разница, реализуются ли они микрокодом или дополнительными схемами в железе
Size: a a a
2021 April 21
BD
а именно поэтому в глибц рантайм патчинг адреса strcpy в зависимости от того что было найдено лучше дла этого проца
BD
оно как кернел вроде не гоняет бенчмарки, но какие-то таблицы выбора там запилены
d
мб cpuid какой-нибудь
DF
Или мудрость поколений
BD
ну проц получить несложно, а бенчи гоняют предварительно обычно
просто линукс на старте гоняет пачку реализаций хеширования и выбирает что быстрее
просто линукс на старте гоняет пачку реализаций хеширования и выбирает что быстрее
BD
а глибц насколько я знаю так не делает, там заранее все отгоняли
IJ
Кстати любопытно что при определенных обстоятельствах гцц генерирует вызов к strcpy типа тут
... но только если хеллоу достаточно длинный. Интересно, как они определили границу: до скольки символов нет вызова. Там чот около 60 емнип
char x[] = "hello";
... но только если хеллоу достаточно длинный. Интересно, как они определили границу: до скольки символов нет вызова. Там чот около 60 емнип
BD
ну потому что эвристически определили что до этой длины побайтовое копирование ок )
BV
про что я и писал выше товарищам что библиотека не отделима от языка
BV
это я ещё забыл сказать про всякие стек гарды
d
написал на годболте аналог memcpy, так компилятор мне его туда и подставил...
BD
ну часть либц уже неотделима вообще ни от чего - llvm генерит вызовы к memcpy для любых языков
BD
поэтому оно в llvm intrinsics уже живет
BV
а будет весело если ты вот напишь свой memcpy и он туда вызов memcpy подставит
BD
я где-то такое видел уже
d
-ffreestanding всё исправилBD
freesttanding не избавляет от intrinsics по-моему
d
у gcc есть libgcc такие штуки видимо там