Почему реализации JITted Python все еще медленные?

Question

Я понимаю, почему издержки интерпретации стоят дорого, но почему реализации JITted Python (Psyco и PyPy) все еще намного медленнее, чем другие языки JITted, такие как C # и Java?

Редактировать: я также понимаю, что все является объектом, динамическая типизация является дорогостоящей и т. Д. Однако для функций, в которых можно определить типы, я не уверен, почему это важно.

Answer 1

Самый простой из возможных ответов заключается в том, что PyPy просто еще не так быстр, как горячая точка, и Psyco никогда этого не сделает.

Написание разумного JIT - долгий и утомительный процесс, и, например, для получения горячей точки потребовалось много летгде это (с большим финансированием также).Чем сложнее и динамичнее язык, тем дольше он длится.С другой стороны, у нас есть хорошие примеры того, как JIT для динамических языков могут быть очень быстрыми, возьмем LuaJIT для одного, который может превзойти C или JVM во многих примерах.

Однако есть и хорошие новости: согласно speed center PyPy стал быстрее в среднем на 27% за последние 100 ревизий, так что в конечном итоге это произойдет.

Answer 2

Люди уже указали на технические детали, поэтому я добавлю еще один фактор: деньги.

За последние несколько лет виртуальные машины Javascript (Google V8, Tracemonkey от Mozilla и Jaegermonkey, Nitro от Apple) предоставили.огромное увеличение скорости для другого динамического языка.Это было в значительной степени обусловлено желанием Google сделать веб-приложения более мощными.У Python просто нет большой компании, которая могла бы выиграть, сделав его в 50 раз быстрее.

О, а интеграция с расширениями C, такими как numpy, означает, что скорость в любом случае редко критична для кода Python.

Answer 3

Python - это динамический язык .

Это означает, что большая часть работы, которую выполняют другие статические языки (например, C # и Java) во время компиляции, выполняется во время выполнения, и это сокращаетPerformance.кода.

например,
Динамическая типизация предотвращает предположения о типе полей / переменных / параметров ..., поэтому любая оптимизация, включающая это, практически невозможна.

EDIT2:
просто пояснение:
когда я говорю время компиляции, я имею в виду также время компиляции JIT, потому что на самом деле JIT является компилятором.
Применение этого к моему первому предложению даетчто Python может выполнять намного меньше работы во время JIT, чем C # или Java ...

Answer 4

Вы не можете реально сравнить динамические языки со статическими языками уровня предприятия.Sun потратила много денег на оптимизацию языка, ВМ и JIT.Microsoft также справилась со своей виртуальной машиной.

Более интересно сравнить динамические языки Jit.Что-то в JavaScript позволяет Google создавать свои V8 быстрее, чем PyPy и ruby ​​1.9 или это просто сумма денег, которую вы вкладываете?

Answer 5

Действительно хороший вопрос. Я не могу дать вам полный ответ, но я думаю, что одной из причин является концепция «все есть объекты, а объект может быть чем угодно». В Java, если вы попробуете «1.getClass ()», он не будет работать, если вы сначала не укажете это, явно или неявно. В Python это работает из коробки. Но объекты определенно более тяжелые, чем примитивные типы, которых у Python просто нет.

Часть «объект может быть чем угодно» еще важнее. Если вы напишите «someobject.somefield» на Java, он будет знать во время компиляции, что такое «somefield», и генерирует код, который обращается к нему напрямую. Что ж, возможно, есть некоторые хитрости для обеспечения лучшей двоичной совместимости, но это не то же самое, что Python, где он фактически выполняет какой-то поиск по словарю во время выполнения, чтобы выяснить, что именно является «неким полем» в данный конкретный момент, поскольку поля быть добавлены и удалены динамически.

Короче говоря, Python более мощный, но эта мощь имеет свою стоимость.

Answer 6

В 2014 году проблема уже не так ясна. Движок Google V8 JS делает довольно тяжелые вещи, чтобы оптимизировать ад из js.

PyPy может быть намного быстрее, если будет доступно только достаточно денег.Скорость выполнения Python в основном не имеет значения, поэтому никто не вкладывает большие средства в PyPy.

Это больше не техническая проблема.Посмотрите на инструкцию Java InvokeDynamic.Конечно, эти вызовы стоят дороже при первом вызове, но JVM может делать магические вещи, как только эти вызовы запускаются.То есть: JVM может делать предположения и узнавать о коде во время его выполнения.Если метод всегда возвращает int, возможно, этот метод всегда возвращает int.На самом деле JVM делает гораздо больше.

В 2014 году она действительно не динамична, а статична с точки зрения производительности.Конечно, C ++ всегда будет самым быстрым инструментом в мире, но динамические языки с джитами не медленнее, чем они были несколько лет назад.

Подождите еще несколько лет, держу пари, что статический анализ намного сильнее в2016 или 2017. В настоящее время выполняется несколько очень интересных исследовательских проектов.

В теории: В принципе, вы можете вывести каждый тип, используя статический анализ типов, вы должны понять что код делает до того, как это сделает.Это не невозможно.

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

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

Итак, по сути: вот много если, я знаю.Но 10 лет назад люди бы рассмеялись, если бы вы сказали им, что js становится настолько быстрым, что вы можете легко писать в нем тяжелые 3d-приложения opengl.

Никогда не стоит недооценивать будущее.

Answer 7

Я понимаю, почему накладные расходы на интерпретацию стоят дорого ...

Сравните эти реализации Python с не-JIT интерпретируемым режимом Java еще раз подумайте над своим вопросом.