Чому Python не був оптимізований як сучасні реалізації Javascript?

Сучасні реалізації JavaScript, такі як V8 (Chrome), SpiderMonkey (Firefox) та Chakra (IE / Edge), мають компіляцію JIT та ряд інших оптимізацій для підвищення продуктивності.

Чому у Python цього немає?

Я дивився на PyPy та IronPython, які обоє заявляють про збільшення швидкості. PyPy Я не розумію, як реалізація Python, написана на інтерпретаційній мові Python, буде швидшою, ніж референтна реалізація в C. IronPython, та сама ідея, але я не бачу, як .NET Framework збільшить швидкість.

Чому у Python цього немає?

Я не впевнений, чому ви думаєте, що немає жодних реалізацій Python, які б мали значення для продуктивності. PyPy , IronPython та Jython - це всі виробничі, готові до виробництва реалізації Python, які турбуються про продуктивність. Pyston - це впровадження, яке було розроблено спеціально для продуктивності. Ластівка без навантаження та 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, який потім знову ж таки додатково компілюється в основний код машини.

Сучасні реалізації JavaScript, такі як V8 (Chrome), SpiderMonkey (Firefox) та Chakra (IE / Edge), мають компіляцію JIT та ряд інших оптимізацій для підвищення продуктивності.

Чому у Python цього немає?

JavaScript включений у веб-браузери, і значна кількість програмного забезпечення сьогодні розроблена для роботи у веб-браузерах. Це робить продуктивність JavaScript дуже важливою, тому що такі компанії, як Google, Apple та Microsoft вкладають багато ресурсів у швидкість виконання JavaScript. Якби цей потік грошей був перенаправлений на Python, це було б однаково швидко.

PyPy Я не розумію, наскільки реалізація Python, написана на Python, інтерпретованій мові, буде швидшою, ніж контрольна реалізація в C.

Ідея полягає в тому, що коли код JIT-ed, він більше не "інтерпретується". PyPI працює, перетворюючи код Python в машинний код (наприклад, машинний код x86_64), який потім виконується безпосередньо на процесорі.

Якщо ви структуруєте свій код python у модулі з простим запуском верхнього рівня в якості основного файлу python (з дуже невеликим кодом у ньому), то python збирає всі решта вашого коду в машинний незалежний байт-код, це .pyc файли, які ви бачите в структурі каталогу. Це мінімізує час завантаження та інтерпретації після першого запуску.

Якщо ви запускаєте свій скрипт зі прапорцями -O або -OO або встановлюєте PYTHONOPTIMIZE значенням більше 0, тоді створюються файли .pyo, які додатково оптимізуються.

Якщо вам потрібна висока оптимізація для певних функцій, ви можете записати їх на C, C ++, FORTRAN або GO, а потім використовувати їх зсередини python.