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

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

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

источник

2010-03-08 dewald

Насколько я знаю, прямо сейчас, не совсем. – zneak

Теоретик заговора может также задуматься о том, может ли MS кодировать JIT для де-оптимизации, если программное обеспечение работает под системой конкурента, например, быть виртуализированным на x86 Mac, предполагая, что они могут обнаружить, что это Mac. – AaronLS

@aaronls: MacBU составляет около 350 миллионов долларов в год для Microsoft. Mac - это * центр прибыли * для Microsoft, который является крупнейшим поставщиком программного обеспечения Mac в мире за пределами самой Apple. Как эти факты вписываются в вашу теорию заговора? –

Снова в 2005 году Дэвид Нотарио перечислил несколько конкретных целевых оптимизаций, это его запись в блоге «Does the JIT take advantage of my CPU?». Я ничего не могу найти о новом CLR 4, но я предполагаю, что в него включены несколько новых элементов.

источник

2010-03-08 23:13:14

Ничего себе. Это одна приятная находка. +1 –

Хорошая ссылка, спасибо. +1 – dewald

Цитата из блога: «мы не вектурируем код (который является реальным выигрышем с SSE2)». К сожалению, JIT не имеет большого преимущества. – colinfang

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

источник

2010-03-08 22:44:36

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

источник

2010-03-08 22:46:41

Есть ли у вас ссылка на поддержку вашего утверждения о том, что MS .NET этого не делает? Не спрашивайте об этом, просто интересно, есть ли это мнение или документированный факт. –

Ну, оказывается, что Microsoft .NET делает несколько оптимизаций на основе набора команд, но не имеет особых характеристик процессора, таких как макет кэша (http://blogs.msdn.com/davidnotario/archive/2005/08/15/451845). ASPX).Моя точка зрения на предварительно скомпилированный код, способный использовать одни и те же оптимизации (и многое другое, что слишком дорого для поиска в компиляторе JIT), по-прежнему сохраняется. –

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

источник

2010-03-08 22:47:03

Да, но размер указателя _always_ меняется, независимо от того, используете ли вы традиционный компилятор или нет. – zneak

32 и 64 бит Jitters отличаются друг от друга, это начало.

источник

2010-03-08 22:47:26

Как я понимаю, OP ищет оптимизацию по конкретным процессорам * в семействе процессоров * (например, генерирует ли он конкретный код в зависимости от текущего процессора на базе микроархитектуры NetBurst против Core, работающей в 32-битном режиме?) –

@Mehrdad, я знаю, что это не главное направление, но я подумал, что это заслуживает упоминания. –

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

источник

2010-03-08 22:54:21 erasmus

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

источник

2010-03-09 15:02:54 kvb

Выполняет ли CLR Microsoft встроенное кэширование? – dewald

@ dewald - Не то, что я знаю, но я считаю, что некоторые виртуальные машины Java. Поскольку методы по умолчанию не являются виртуальными в C# (в отличие от Java), я считаю, что это был более низкий приоритет для .NET. Однако это только один пример того, как оптимизация может быть выполнена во время выполнения JIT, которые трудно или невозможно сделать статически. – kvb

@dewald - См http://stackoverflow.com/questions/1255803/does-the-net-clr-jit-compile-every-method-every-time больше на контрасте между CLR и подходами JVM. – kvb

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

ответ

Смежные вопросы