Расширенные инструкции процессора в .NET или «C# Intrinsics»

[sidristij]

Круто, фактически патчинг JITter =)

[GreyCat]

Надо учесть Call-Convention, благо на x86_64 он один

Кстати, если формально — то два, в UNIX-мире соглашение другое. Если хотите сделать код портируемым хотя бы на x86_64 + Mono — имеет смысл сделать детект и поддержку SysV-варианта.

[atd]

Да, там сейчас проверяется на всякий случай пролог функции, и в моно он будет другим. Для моно не стал делать отдельного патча, потому что если требуется «выжать ещё немного скорости», то лучше пересесть с моно на дотнет, а если нет винды, то на c++ или jvm.

[kekekeks]

На моно не надо патчить, он сам умеет всё нужное. См. Mono.Simd

[atd]

А там есть popcnt/bsf/bsr? Насколько я понял, оно умеет только SIMD инструкции, а нужные нам к ним не относятся, хотя появились примерно вместе с ними.

[a553]

А в 90-х мы так делали для инструкций x87 процессора на тот случай, если его нет. :)

[WGH]

Применительно к конечному алгоритму я получил ускорение всего-лишь на 15%

«Всего лишь»? По-моему это очень неплохо.

[atd]

это по сравнению с ускорениями до 100× в бенчмарках )

[DreamWalker]

Прежде всего хочется скачать большое спасибо за пост. Получил большое удовольствие от чтения. А теперь немного конструктивной критики.

Бенчмарки довольно примитивные: генерируем массив псевдо-случайных чисел, потом гоняем по нему 100млн раз каждый метод. Чтобы исключить влияние цикла и прочей обвязки, сначала измеряем время пустого цикла.

Хотелось бы более интеллекутальных бенчмарков.

1. Нет прогрева и множественных замеров. Для получения действительно хороших результатов нужно сначала каждый тест прогнать несколько раз вхолостую, затем несколько раз с замером времени, взять среднее значение и обратить внимание на то, как «пляшет» время от запуску к запуску. Для автоматизации можете попробывать BenchmarkDotNet.
2. Нет анализа того, как проводится развёртка цикла. Обычный JIT весьма коварен в этом плане. Иногда складывается такое ощущение, что он может принимать решение о развёртке цикла в зависимости от фазы луны. Если получится так, что в одних тестах цикл разворачивается, а в других — нет, то это очень грустно.
3. Не указан размер кеша процессора и не сделаны выводы о возможных cache-miss-ах. При изменении размера массива они могут оказать значительное влияние на результаты бенчмарка.
4. Да и в целом хорошо бы погонять бенчмарки на массивах разных размеров, чтобы исключить непредвиненные сайд-эффекты.
5. Не помешает выставить ProcessorAffinity-маску, чтобы рантайм не перекидывал ваше приложение с одного ядра на другое — от этого опять-таки могут возникнуть неприятные сайд-эффекты.
6. Скоро на экранах появится RuyJIT. Было бы здорово и на нём проверить вашу логику.

Хотелось бы уточнить: я не говорю, что ваши бенчмарки дают неверные результаты. Возможно, что ни один сайд эффект не сработал, и временные замеры получились более или менее адекватные. Но просто так брать и доверять результатам бенчмарков нельзя — необходим более глубокий и внимательный подход.

[atd]

Спасибо за конструктивную критику. Конечно, бенчмарки примитивные, просто не хотелось тратить на них много усилий.
В итоге я замерил ускорение на реальном проекте и успокоился на этом )

RyuJIT самому интересно посмотреть, но они (msft) сообщают, что он пока не готов, и сам тормознее текущей версии на 10-20%