Які смислові особливості Python (та інших динамічних мов) сприяють його повільності?
Немає.
Виконання мовних реалізацій - це функція грошей, ресурсів та кандидатських дисертацій, а не особливості мови. Self є набагато більш динамічним, ніж Smalltalk і трохи більш динамічним, ніж Python, Ruby, ECMAScript або Lua, і він мав VM, що перевершував усі існуючі VM Lisp і Smalltalk (насправді, саморозподіл постачався разом з невеликим перекладачем Smalltalk, написаним у Self , і навіть це було швидше, ніж більшість існуючих VM Smalltalk), і було конкурентоспроможним, а іноді навіть швидшим, ніж впровадження C ++ того часу.
Тоді Sun не припинила фінансувати Self, і IBM, Microsoft, Intel та Co. почали фінансувати C ++, і тенденція змінилася. Розробники Self залишили Sun створити власну компанію, де вони використовували технологію, розроблену для Self VM, щоб створити один з найшвидших віртуальних машин Smalltalk коли-небудь (Animorphic VM), а потім Sun викупила цю компанію, і трохи змінену версію що Smalltalk VM тепер більше відомий під назвою "HotSpot JVM". За іронією долі, програмісти Java дивляться на динамічні мови, оскільки вони є "повільними", а фактично - Javaйшло повільно, поки не було прийнято динамічну технологію мови. (Так, саме так: JVM HotSpot - це, по суті, Smalltalk VM. Перевірявач байт-коду робить багато перевірки типів, але як тільки байт-код приймається верифікатором, VM, а особливо оптимізатор і JIT насправді не роблять великий інтерес до статичних типів!)
CPython просто не робить багато того, що робить динамічні мови (а точніше динамічну диспетчеризацію) швидкими: динамічна компіляція (JIT), динамічна оптимізація, спекулятивне вбудовування, адаптивна оптимізація, динамічна деоптимізація, динамічний зворотний зв'язок / умовивід. Існує також проблема в тому, що майже вся основна і стандартна бібліотека написана на C, це означає, що навіть якщо ви зробите Python 100x швидше, це вам не дуже допоможе, тому що щось на зразок 95% коду, виконаного Програма Python - це C, а не Python. Якби все було написано в Python, навіть помірні прискорення створювали б ефект лавини, коли алгоритми стають швидшими, а основні структури даних - швидшими, але, звичайно, основні структури даних також використовуються в межах алгоритмів, а основні алгоритми та основні дані структури використовуються скрізь,
Є кілька речей, які, як відомо, погані для мов OO, керованої пам'яттю (динамічні чи ні) в сучасних системах. Захист віртуальної пам’яті та пам’яті може бути вбивцею зокрема для вивезення сміття, а також для роботи системи в цілому. І це абсолютно непотрібно для безпечної для пам’яті мови: навіщо захищати від незаконного доступу до пам’яті, коли в мові немає жодного доступу до пам’яті? Azul придумав використовувати сучасні потужні MMU (Intel Nehalem і новіші, і AMD-еквівалент), щоб допомогти збору сміття замість того, щоб перешкоджати цьому, але, хоча це підтримується процесором, поточні підсистеми пам'яті в основному ОС недостатньо потужні щоб це (саме тому JVM Azul фактично біжить віртуалізувати на голий метал , крім ОС, а не всередині неї).
У проекті Singularity OS Microsoft виміряла вплив на 30% на продуктивність системи при використанні захисту MMU замість системи типу для поділу процесу.
Інша річ, яку Azul зауважив, будуючи свої спеціалізовані процесори Java, - це те, що сучасні основні процесори зосереджуються на абсолютно неправильній справі, намагаючись зменшити витрати на пропуски кешу: вони намагаються зменшити кількість пропусків кешу за допомогою таких завдань, як передбачення гілок, попереднє завантаження пам'яті, і так далі. Але у сильно поліморфній програмі ОО схеми доступу в основному є псевдовипадковими, просто передбачити нічого немає. Отже, всі ці транзистори просто марно витрачаються, а те, що потрібно робити замість цього, - це зменшити вартість кожної пропущеної окремої кеши. (Загальна вартість - це #misses * cost; mainstream намагається збити перше, а Azul - друге.) Java Compute Accelerators Azul може мати 20000 одночасних пропусків кешу в польоті і все ж робити прогрес.
Коли Azul запустився, вони думали, що вони візьмуть кілька нестандартних компонентів вводу / виводу і розробити власне спеціалізоване ядро процесора, але те, що їм насправді потрібно було зробити, було з точністю до навпаки: вони взяли досить стандартний режим відключення 3-адресна ядро RISC на шельфі і розроблено власний контролер пам'яті, MMU та підсистему кешу
tl; dr : "повільність" Python - це не властивість мови, а а) її наївна (первинна) реалізація; і b) факт, що сучасні процесори та ОС спеціально розроблені для швидкого запуску C, і їхніх функцій have для C або не допомагають (кешувати), або навіть активно шкодять (віртуальна пам'ять) продуктивність Python.
І тут ви можете вставити майже будь-яку мову, керовану пам'яттю, з динамічним спеціальним поліморфізмом ... коли мова йде про проблеми ефективної реалізації, навіть Python та Java майже «одна і та ж мова».