Почему IronPython быстрее официального интерпретатора Python

Согласно этому:

http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP20VsCPy25Perf&referringTitle=IronPython%20Performance

IronPython (Python для .Net) работает быстрее, чем обычный Python (cPython) на той же машине. Почему это? Я бы подумал, что скомпилированный код C всегда будет быстрее, чем эквивалентный байт-код CLI.


python performance ironpython
person Tristan Havelick    schedule 02.02.2009    source источник
comment
Я не уверен, что cPython является более официальным Jython или IronPython. См. docs.python.org/reference/.   -  person S.Lott    schedule 03.02.2009
comment
@S.Lott: это не Python, но это реализация по умолчанию просто потому, что она была первой.   -  person Joachim Sauer    schedule 03.02.2009
comment
Python не компилируется в C   -  person Ed S.    schedule 07.03.2009
comment
...ошибаться, как уже указал Коди. Прости.   -  person Ed S.    schedule 07.03.2009
comment
Согласно этому smallshire. org.uk/sufficientlysmall/2009/05/17/ это не так.   -  person Aleksandr Dubinsky    schedule 11.03.2015
comment
Железный питон не имеет GIL (глобальной блокировки интерпретатора), поэтому многопоточный код должен работать быстрее. wiki.python.org/moin/IronPython   -  person MichaelMoser    schedule 12.11.2017

Ответы (5)


arrow_upward
41
arrow_downward

Код Python не компилируется в C, сам Python написан на C и интерпретирует байт-код Python. CIL компилируется в машинный код, поэтому вы видите лучшую производительность при использовании IronPython.

person Serafina Brocious    schedule 02.02.2009
comment
Однако есть одна загвоздка. Я согласен с тем, почему IronPython быстрее. IronPython медленнее с точки зрения времени запуска. (Что не важно, если вы используете код регулярно.) - person ozgur; 05.05.2016

arrow_upward
9
arrow_downward

Вы правы, C намного быстрее. Вот почему в этих результатах CPython в два раза быстрее, когда речь идет о словарях, которые являются почти чистым C. С другой стороны, код Python не компилируется, он интерпретируется. Вызовы функций в CPython ужасно медленные. Но с другой стороны:

TryRaiseExcept:  +4478.9%

Вот где IronPython ужасно ошибается.

А еще есть этот проект PyPy, одной из целей которого является компилятор Just-In-Time. Существует даже подмножество Python, называемое RPython (Reduced Python), которое можно статически скомпилировать. Что, конечно, намного быстрее.

person vartec    schedule 03.02.2009
comment
Мне всегда было интересно, почему RPython не получил большего продвижения. Он достаточно динамичен, чтобы быть полезным, но при этом очень быстр. Если бы для него было больше документации, я бы обязательно его использовал. - person Daishiman; 07.03.2009
comment
Команда PyPy на самом деле не хочет поощрять людей использовать RPython. Они рассматривают его как деталь реализации PyPy — он постоянно меняется, имеет плохую документацию и ужасные отчеты об ошибках. Они сосредоточены на том, чтобы сделать PyPy JIT достаточно быстрым, чтобы вам не нужно использовать RPython для увеличения скорости... - person fuzzyman; 05.10.2009
comment
RPython не предназначен для использования (и даже не для ухода разработчика). Это просто подмножество, которое PyPy использует для компиляции. Если я правильно понимаю, подмножество, часть вашего кода будет скомпилирована, а некоторые все еще будут интерпретированы. - person ozgur; 05.05.2016

arrow_upward
5
arrow_downward

Я не уверен, как именно вы делаете вывод, что IronPython быстрее, чем CPython. Ссылка, которую вы публикуете, похоже, указывает на то, что они хороши в разных вещах (например, в исключениях, как было указано).

person Jason Baker    schedule 07.03.2009

arrow_upward
5
arrow_downward

Переход от вашего вопроса «Почему?» к «О, правда?» «Хороший в разных вещах» (Джейсон Бейкер) прав. Например, cpython превосходит IronPython по времени запуска.

c:\Python26\python.exe Hello.py
c:\IronPython\ipy.exe Hello.py

Cpython выполняет базовый приветственный мир почти мгновенно (‹100 мс), в то время как у IronPython накладные расходы на запуск составляют 4 или 5 секунд. Это меня раздражает, но не настолько, чтобы удержать меня от использования IronPython.

person Precipitous    schedule 06.05.2009
comment
Это не преимущество CPython перед IronPython для себя. 4 или 5 секунд — это время запуска CLR, а не IronPython. - person Rafa Castaneda; 10.03.2010
comment
Неважно, почему для запуска требуется на 4 или 5 секунд больше. После запуска он работает быстрее (частично для CLR), но медленнее запускается (частично из-за CLR). Соображения производительности имеют значение, основанное на воздействии на пользователя. Если вариант использования языка сценариев состоит из множества небольших сценариев, это серьезный недостаток. - person Precipitous; 18.03.2010
comment
Возможно, время запуска IronPython можно сократить за счет одноразового действия по предварительному созданию машинного кода для IronPython .dll? См. Microsoft Ngen.exe (генератор собственных образов) msdn .microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx - person ToolmakerSteve; 19.12.2013
comment
Как было указано в другом месте, в Mono есть концепция компиляции с опережением времени (AOT), которая объясняется на ее страницы документа. Это уменьшит время запуска и время работы в некоторых случаях, но оно ограничено определенными процессорами (обычными). - person dirkjot; 16.05.2014

arrow_upward
4
arrow_downward

Может ли это быть объяснено этой записью на странице, на которую вы ссылаетесь:

Из-за кэширования сайта в среде выполнения Dynamic Language Runtime IronPython работает лучше с большим количеством проходов PyStone, чем значение по умолчанию.

person Abtin Forouzandeh    schedule 02.02.2009
comment
Без знания того, что такое кэширование сайта (очень сложная концепция, объясненная только в серии видеороликов на Channel9), это ничего вам не говорит. Кроме того, IPy1 (предшествовавший DLR) также имел лучшую производительность, чем CPython. Все сводится к компиляции CIL. - person Serafina Brocious; 02.02.2009