Делает CLR.NET, действительно оптимизируют для текущего процессора
Когда я читал о производительности языков JITted как C# или Java, авторы обычно говорят, что они должны теоретически превзойти много скомпилированных собственными компонентами приложений по характеристикам. Так как теория - это, исходные приложения обычно просто компилируются для семейства процессоров (как x86), таким образом, компилятор не может сделать определенную оптимизацию, поскольку они не могут действительно быть оптимизацией на всех процессорах. С другой стороны, CLR может сделать определенную для процессора оптимизацию во время процесса JIT.
Кто-либо знает, выполняет ли Microsoft (или Mono) CLR на самом деле определенную для процессора оптимизацию во время процесса JIT? Если так, какой оптимизация?
7 ответов
Еще в 2005 году Дэвид Нотарио перечислил несколько конкретных целевых оптимизаций в своей записи в блоге « Использует ли JIT преимущества моего процессора? ". Я ничего не могу найти о новом CLR 4, но думаю, что в него включено несколько новых элементов.
32- и 64-битные джиттеры отличаются, это уже начало.
Я отмечу, что основная причина, о которой я слышу, о потенциале JIT-скомпилированных языков превосходить статически скомпилированные языки, не имеет ничего общего с процессором. конкретные инструкции. Вместо этого информация о динамическом состоянии программы может использоваться для оптимизации путей кода. Например, встроенное кэширование может использоваться для выполнения вызовов виртуальных методов примерно так же быстро, как и вызовы невиртуальных методов. Грубо говоря, это работает, предполагая, что в конкретном месте вызова метод вызывается только для одного типа и генерирует код, который переходит непосредственно к этой реализации (а затем переписывает код, если это предположение не подтверждается позже).
.Net Framework Runtime Optimization Service оптимизирует не только проблемы программирования (оптимизация компилятора), но и процессоры.
Я знаю правила, по которым встроенные функции меняются в зависимости от типа процессора (x86, x64). И, конечно, размеры указателя будут варьироваться в зависимости от того, работает он как 32-битный или 64-битный.
Одна оптимизация под конкретный процессор, о которой я знаю, сделана в Mono - это компиляция вызовов Mono.Simd до инструкций SSE на процессорах, поддерживающих SSE. Если процессор, на котором выполняется код, не поддерживает SSE, JIT-компилятор выдаст эквивалентный не-SSE код.
Я думаю, что некоторые компиляторы Java делают это, а Microsoft .NET - нет, и он выигрывает у precompiled только тогда, когда вы сравниваете яблоки с апельсинами. Precompiled может поставляться с вариантами библиотек, настроенных на разные процессоры (или, что более вероятно, на разные наборы инструкций), и проверка во время выполнения, чтобы выбрать, какую библиотеку загрузить, намного дешевле, чем JIT. Например, mplayer делает это (google для mplayer enable-runtime-cpudetection).