Динамическая производительность языка .NET?

Question

Я понимаю, что IronPython - это реализация Python на платформе .NET, точно так же, как IronRuby - это реализация Ruby, а F # - более или менее OCaml.

То, что я не могу понять, так это то, работают ли эти языки ближе к своим "предкам" или ближе к чему-то вроде C # с точки зрения скорости. Например, IronPython каким-то образом «скомпилирован» до того же байт-кода, который используется в C #, и, следовательно, будет работать так же быстро?

Answer 1

IronPython и IronRuby построены на основе DLR - динамического языка исполнения - и компилируются в CIL (байт-код, используемый в .NET) на лету. Они медленнее, чем C #, но работают быстрее, чем их не-.NET-аналоги. Насколько я знаю, там нет приличных тестов, но вы увидите разницу.

Answer 2

IronPython на самом деле является самой быстрой реализацией Python. По крайней мере, для некоторого определения «самый быстрый»: издержки запуска CLR, например, составляют огромный по сравнению с CPython. Кроме того, оптимизирующий компилятор IronPython имеет смысл, только когда код выполняется несколько раз.

IronRuby потенциально может быть столь же быстрым IronPython, так как многие интересные функции, которые делают IronPython быстрым, были извлечены в динамическую языковую среду выполнения, в которой и IronPython, и IronRuby (и управляемый JavaScript, Dynamic VB, IronScheme, VistaSmalltalk и другие) построены.

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

Например, Common Lisp - это язык, который еще более динамичен, чем Ruby или Python, и все же есть компиляторы Common Lisp, которые могут даже запустить C за свои деньги. Хорошие реализации Smalltalk работают так же быстро, как и Java (что неудивительно, поскольку обе основные JVM, Sun HotSpot и IBM J9, на самом деле являются лишь слегка модифицированными виртуальными машинами Smalltalk) или C ++. Всего за последние 6 месяцев основные реализации JavaScript (Mozilla TraceMonkey, Apple SquirrelFish Extreme и новый разработчик Google V8) достигли огромных улучшений производительности, в 10 и более раз, чтобы обеспечить JavaScript на голову в лоб с неоптимизированным C.

Answer 3

Вы правильно поняли, предполагая, что производительность современной реализации .NET будет между производительностью предка и C #. Причина в том, что C # очень близко соответствует самому .NET.

F # - легкая задача, потому что C # и OCaml сами имеют схожие характеристики производительности.

IronPython намного сложнее, потому что Python и C # имеют совершенно разные характеристики производительности. Фактически, ответ зависит от самой реализации IronPython, которая будет стремиться по возможности преобразовывать неэффективную оценку в стиле Python в эффективную оценку в стиле C #. Ожидайте, что IronPython будет намного медленнее, чем C #, с редкими всплесками на той же территории. Вы можете увидеть этот эффект здесь .

Ура, Джон Харроп.

Answer 4

В настоящее время IronRuby довольно медленный в большинстве случаев. Это определенно медленнее, чем MRI (реализация Matz 'Ruby) в целом, хотя в некоторых местах они быстрее.

IronRuby действительно может быть намного быстрее, хотя я сомневаюсь, что они когда-нибудь приблизятся к C # с точки зрения скорости. В большинстве случаев это просто не имеет значения. Например, вызов базы данных будет составлять 90% от общей продолжительности веб-запроса.

Я подозреваю, что в первую очередь команда будет стремиться к полноте языка, а не к производительности. Это позволит вам запускать IronRuby и запускать большинство программ ruby, когда появится 1.0, тогда они могут улучшать производительность по мере их поступления.

Я подозреваю, что у IronPython похожая история.