Комментарии 10
Круто, фактически патчинг JITter =)
+5
Надо учесть Call-Convention, благо на x86_64 он один
Кстати, если формально — то два, в UNIX-мире соглашение другое. Если хотите сделать код портируемым хотя бы на x86_64 + Mono — имеет смысл сделать детект и поддержку SysV-варианта.
0
На моно не надо патчить, он сам умеет всё нужное. См. Mono.Simd
0
А в 90-х мы так делали для инструкций x87 процессора на тот случай, если его нет. :)
+3
Применительно к конечному алгоритму я получил ускорение всего-лишь на 15%
«Всего лишь»? По-моему это очень неплохо.
0
Прежде всего хочется скачать большое спасибо за пост. Получил большое удовольствие от чтения. А теперь немного конструктивной критики.
Хотелось бы более интеллекутальных бенчмарков.
Хотелось бы уточнить: я не говорю, что ваши бенчмарки дают неверные результаты. Возможно, что ни один сайд эффект не сработал, и временные замеры получились более или менее адекватные. Но просто так брать и доверять результатам бенчмарков нельзя — необходим более глубокий и внимательный подход.
Бенчмарки довольно примитивные: генерируем массив псевдо-случайных чисел, потом гоняем по нему 100млн раз каждый метод. Чтобы исключить влияние цикла и прочей обвязки, сначала измеряем время пустого цикла.
Хотелось бы более интеллекутальных бенчмарков.
- Нет прогрева и множественных замеров. Для получения действительно хороших результатов нужно сначала каждый тест прогнать несколько раз вхолостую, затем несколько раз с замером времени, взять среднее значение и обратить внимание на то, как «пляшет» время от запуску к запуску. Для автоматизации можете попробывать BenchmarkDotNet.
- Нет анализа того, как проводится развёртка цикла. Обычный JIT весьма коварен в этом плане. Иногда складывается такое ощущение, что он может принимать решение о развёртке цикла в зависимости от фазы луны. Если получится так, что в одних тестах цикл разворачивается, а в других — нет, то это очень грустно.
- Не указан размер кеша процессора и не сделаны выводы о возможных cache-miss-ах. При изменении размера массива они могут оказать значительное влияние на результаты бенчмарка.
- Да и в целом хорошо бы погонять бенчмарки на массивах разных размеров, чтобы исключить непредвиненные сайд-эффекты.
- Не помешает выставить ProcessorAffinity-маску, чтобы рантайм не перекидывал ваше приложение с одного ядра на другое — от этого опять-таки могут возникнуть неприятные сайд-эффекты.
- Скоро на экранах появится RuyJIT. Было бы здорово и на нём проверить вашу логику.
Хотелось бы уточнить: я не говорю, что ваши бенчмарки дают неверные результаты. Возможно, что ни один сайд эффект не сработал, и временные замеры получились более или менее адекватные. Но просто так брать и доверять результатам бенчмарков нельзя — необходим более глубокий и внимательный подход.
+3
Спасибо за конструктивную критику. Конечно, бенчмарки примитивные, просто не хотелось тратить на них много усилий.
В итоге я замерил ускорение на реальном проекте и успокоился на этом )
RyuJIT самому интересно посмотреть, но они (msft) сообщают, что он пока не готов, и сам тормознее текущей версии на 10-20%
В итоге я замерил ускорение на реальном проекте и успокоился на этом )
RyuJIT самому интересно посмотреть, но они (msft) сообщают, что он пока не готов, и сам тормознее текущей версии на 10-20%
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширенные инструкции процессора в .NET или «C# Intrinsics»