Имеет ли смысл переписывать memcpy/memcmp/... с инструкциями SIMD в крупномасштабном программном обеспечении?
Если да, то почему GCC по умолчанию не генерирует SIMD-инструкции для этих библиотечных функций?
Кроме того, есть ли какие-либо другие функции, которые можно улучшить с помощью SIMD?
Да, эти функции намного быстрее с инструкциями SSE. Было бы неплохо, если бы ваша библиотека/компилятор времени выполнения включала в себя оптимизированные версии, но это, похоже, не повсеместно.
У меня есть собственный SIMD memchr, который чертовски быстрее библиотечной версии. Особенно, когда я нахожу первый из 2 или 3 символов (например, я хочу знать, есть ли уравнение в этой строке текста, я ищу первый из =, \n, \r).
С другой стороны, библиотечные функции хорошо протестированы, поэтому писать свои собственные стоит только в том случае, если вы их часто вызываете, а профилировщик показывает, что они занимают значительную долю вашего процессорного времени.
memcpy предназначены для тысяч байтов. У вас может легко быть вызов memcpy для ~ 20 байтов внутри цикла с другой обработкой. (2) Современные ядра ЦП не ограничиваются обработкой инструкций из одного потока, поэтому я упомянул гиперпоточность. (3) Задержка DRAM менее важна при конвейерной предварительной выборке чтения, важна только пропускная способность. (4) Даже если пропускная способность DRAM тормозит код, все же лучше выполнять копирование эффективно, поскольку ЦП может выполнять работу за то же время и с меньшим энергопотреблением (например, динамически снижая тактовую частоту).
- person Ben Voigt; 16.03.2011
memchr? У Glibc есть написанные от руки ассемблерные версии memchr / strchr / memmove и так далее для i386 и x86-64 (и большинства других ISA), которые отлично подходят для больших буферов, и многие из них также имеют хорошие стратегии для малых буферов. (С диспетчеризацией времени выполнения через разрешение символов динамического компоновщика, поэтому он может использовать AVX2 на совместимых процессорах даже в двоичных файлах, скомпилированных без -mavx2). Главное, что вы можете получить, это если вы знаете, что ваш буфер выровнен и/или имеет длину не менее 16 байт, чтобы вы могли избежать ветвления для выбора стратегии.
- person Peter Cordes; 11.02.2020
vpcmpeqb из 4 векторов, затем соедините их все вместе, чтобы сэкономить на vpmovmskb + test операций в секунду, с разветвлением цикла один раз на 2 строки кэша.
- person Peter Cordes; 11.02.2020
Это не имеет смысла. Ваш компилятор должен неявно генерировать эти инструкции для встроенных функций memcpy/memcmp/similar, если он вообще может генерировать SIMD.
Возможно, вам потребуется явно указать GCC для генерации кодов операций SSE с помощью например, -msse -msse2; некоторые GCC не включают их по умолчанию. Кроме того, если вы не укажете GCC оптимизировать (т. е. -o2), он даже не попытается создать быстрый код.
Использование кодов операций SIMD для такой работы с памятью может иметь огромное влияние на производительность, поскольку они также включают предварительную выборку из кэша и другие подсказки DMA, которые важны для оптимизации доступа к шине. Но это не значит, что вам нужно создавать их вручную; даже несмотря на то, что большинство компиляторов в целом плохо генерируют SIMD-операции, каждый из тех, что я использовал, по крайней мере, обрабатывает их для основных функций памяти CRT.
Базовые математические функции также могут значительно выиграть от перевода компилятора в режим SSE. Вы можете легко получить 8-кратное ускорение на базовом sqrt(), просто говорит компилятору использовать код операции SSE вместо ужасного старого x87 FPU.
memcpy, скорее всего, будет должным образом оптимизирован. Многие другие функции из <string.h> и <memory.h> также очень полезны и не оптимизированы компилятором.
- person Ben Voigt; 16.03.2011
repne scasb strlen в -O1 или сложный 32- побитовый битхак в -O2, который не использует преимущества SSE2. Программа полностью зависит от производительности strlen для огромных буферов, поэтому вызов оптимизированной версии glibc является большой победой. Существует большая разница между библиотекой и встроенным.
- person Peter Cordes; 11.02.2020
Это вероятно не имеет значения. ЦП намного быстрее, чем пропускная способность памяти, и реализации memcpy и т. д., предоставляемые библиотекой времени выполнения компилятора, вероятно, достаточно хороши. В «крупномасштабном» программном обеспечении ваша производительность в любом случае не будет зависеть от копирования памяти (вероятно, доминирует ввод-вывод).
Чтобы добиться реального повышения производительности копирования памяти, в некоторых системах имеется специализированная реализация DMA, который можно использовать для копирования из памяти в память. Если требуется существенное увеличение производительности, аппаратное обеспечение — это способ добиться этого.
на оборудовании x86 это не должно иметь большого значения, с неупорядоченной обработкой. Процессор добьется необходимого ILP и попытается выполнить максимальное количество операций загрузки/сохранения за такт для memcpy, будь то набор инструкций SIMD или Scalar.
memcpyна самом деле является худшим случаем для встроенной функции SSE, потому что SSE нельзя использовать для крайних случаев. Выдают ли эти компиляторы код SIMD дляstrlenиmemchr? - person Ben Voigt schedule 16.03.2011