Почему в Python их нет?
Я не уверен, почему вы думаете, что нет реализаций Python, которые заботятся о производительности. PyPy , IronPython и Jython - это промышленные, готовые к реализации реализации Python, которые заботятся о производительности. Pyston - это находящаяся в разработке реализация, специально созданная для повышения производительности. Unladen Swallow и Psyco были также проектами по улучшению производительности Python.
Однако тот факт, что пользователи CPython значительно превосходят общую совокупную базу пользователей всех других реализаций, что Unladen Swallow был отвергнут сообществом, что большинство этих проектов либо мертвы, либо пытаются привлечь разработчиков, должны рассказать вам о том, как Python сообщество ценит производительность.
Этот ответ является хорошим примером типичного менталитета сообщества Python: вместо того, чтобы исправлять проблемы с производительностью, они просто предпочли бы писать свой код не на Python.
Я смотрел на PyPy и IronPython, которые оба претендуют на увеличение скорости. PyPy Я не понимаю, как реализация Python, написанная на Python, интерпретируемом языке, будет быстрее, чем эталонная реализация на C.
Прежде всего: не имеет значения, на каком языке написан компилятор. В конце концов, компилятор выполняется только один раз , поэтому, даже если он был медленным, это не имеет значения: производительность компилятора не имеет значения, что важно это производительность вывода компилятора.
Во-вторых, поскольку значение имеет только то, насколько быстро выводится компилятор, а компилятор написан на Python, то есть на языке, который он компилирует, он может на самом деле сделать себя быстро, компилируя себя.
В-третьих, не существует такого понятия, как «интерпретируемый язык». Язык - это набор математических правил и ограничений. Это спецификация. Лист бумаги. Язык не компилируется и не интерпретируется. Язык просто есть . Компиляция и интерпретация - это черты языковой реализации , точнее, компилятора или интерпретатора (дух!), А не языка. Каждый язык может быть реализован компилятором. Любой язык может быть реализован переводчиком. Вы можете механически генерировать компилятор из интерпретатора и интерпретатор из компилятора.
Но все это на самом деле не имеет значения, потому что PyPy на самом деле не написан на Python. Это написано в RPython . RPython состоит из двух частей: языка программирования RPython и инфраструктуры RPython.
Язык программирования RPython не является Python. Это другой язык программирования. RPython - это статически типизированный язык программирования, примерно на том же уровне абстракции, что и Java, с примерно той же производительностью, что и C. RPython - это синтаксическое и семантическое подмножество Python, что означает, что каждая программа RPython является допустимой программой Python и может запускаться реализацией Python (хотя, как правило, на несколько порядков медленнее, но это все же полезно для отладки, потому что вы получаете доступ ко всем инструментам Python, и интерпретация начинается сразу же, тогда как компиляция языковой реализации обычно занимает около 5-10 минут ), но обратное неверно.
Фреймворк RPython - это фреймворк для написания высокопроизводительных реализаций динамического языка на языке программирования RPython. Он включает в себя сборщик мусора, пространство объектов, протокол мета-объектов, предварительно определенные объекты, типы и операции и т. Д. Но главная особенность - его способность автоматически генерировать JIT-компилятор из интерпретатора: если вы реализуете язык в среде RPython, вам нужно только написать интерпретатор, а среда RPython позаботится о JIT.
Существует множество языковых реализаций на платформе RPython , а не только PyPy.
IronPython, та же идея, но я не вижу, как .NET Framework увеличит скорость.
Большинство реализаций ISO CLI, таких как различные варианты .NET от Microsoft или Mono, содержат сложные сборщики мусора, оптимизаторы и компиляторы. То же самое верно для реализаций Jython и Java.
IronPython - это компилятор, он компилирует исходный код Python в деревья DLR (DLR - динамическая среда исполнения языка), которые затем дополнительно компилируются в байтовый код CIL, который затем снова обычно компилируется в машинный код.