Действительно ли .NET CLR действительно оптимизируется для текущего процессора

Question

Когда я читаю о производительности языков JITted, таких как C # или Java, авторы обычно говорят, что они должны / могут теоретически превзойти многие нативно скомпилированные приложения. Теория заключается в том, что нативные приложения обычно просто компилируются для семейства процессоров (например, x86), поэтому компилятор не может выполнять определенные оптимизации, поскольку они могут не являться оптимизациями для всех процессоров. С другой стороны, CLR может выполнять специфичные для процессора оптимизации во время процесса JIT.

Кто-нибудь знает, действительно ли CLR от Microsoft (или Mono) выполняет специфичные для процессора оптимизации во время процесса JIT? Если да, то какие оптимизации?

Answer 1

Еще в 2005 году Дэвид Нотарио перечислил несколько конкретных целевых оптимизаций в своей записи в блоге " Использует ли JIT преимущества моего ЦП? ". Я не могу найти что-нибудь о новом CLR 4, но я думаю, что в него включено несколько новых предметов.

Answer 2

Одна оптимизация для конкретного процессора, о которой мне известно, что в Mono выполняется компиляция Mono.Simd вызовов до инструкций SSE для процессоров, поддерживающих SSE. Если процессор, выполняющий код, не поддерживает SSE, JIT-компилятор выведет эквивалентный код не-SSE.

Answer 3

Я укажу, что основная причина, по которой я слышал, заключается в том, что языки, скомпилированные JIT, превосходят статически скомпилированные языки, не имеют ничего общего с инструкциями, специфичными для процессора. Вместо этого именно информация о динамическом состоянии программы может использоваться для оптимизации путей кода. Например, встроенное кэширование может использоваться для выполнения вызовов виртуальных методов примерно так же быстро, как вызовы не виртуальных методов. Грубо говоря, это работает, предполагая, что на определенном сайте вызова метод вызывается только для одного типа, и испуская код, который переходит непосредственно к этой реализации (и затем переписывает код, если это предположение не подтверждается позже).

Answer 4

.Net Framework Runtime Optimization Service оптимизирует не только проблемы программирования (оптимизация компилятора), но и процессоры.

Answer 5

32 и 64-битные джиттеры разные, это начало.

Answer 6

Я думаю, что некоторые компиляторы Java делают, Microsoft .NET нет, и это лучше, чем предварительно скомпилированные, когда вы сравниваете яблоки с апельсинами. Предварительно скомпилированный может поставляться с вариантами библиотеки, настроенными на разные процессоры (или, более вероятно, разные наборы команд), и проверка во время выполнения, чтобы выбрать, какую библиотеку загружать, намного дешевле, чем JIT. Например, mplayer делает это (Google для mplayer enable-runtime-cpudetection).

Answer 7

Я знаю, правила для встроенных функций изменяются в зависимости от типа процессора (x86, x64). И, конечно, размеры указателя будут варьироваться в зависимости от того, работает ли он как 32-разрядный или 64-разрядный.