Состоялся (https://morepypy.blogspot.ru/2017/10/pypy-v59-released-now-s...) новый выпуск проекта PyPy 5.9 (http://pypy.org/), в рамках которого развивается реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython (http://doc.pypy.org/en/latest/coding-guide.html#id1), Restricted Python). Выпуск подготовлен одновременно для веток PyPy2.7 и PyPy3.5, обеспечивающих поддержку синтаксиса Python 2.7 и Python 3.5, и поставляемых с stdlib 2.7.13 и 3.5.3. Выпуск PyPy2.7 5.9 доступен для Linux (x86, x86_64, PPC64, s390x, ARMv6 или ARMv7 с VFPv3), macOS и Windows, а выпуск PyPy3.5 5.9, который пока не вышел из стадии бета-версии, только для Linux x86_64.
Особенностью PyPy является использование JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, что позволяет обеспечить высокий (http://speed.pypy.org/) уровень производительности - при выполнении некоторых операций PyPy в несколько раз обгоняет классическую реализацию Python на языке Си (CPython). Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
Основные улучшения (http://doc.pypy.org/en/latest/release-v5.9.0.html):
- В PyPy2.7 обеспечена полноценная поддержка приложений, написанных с использованием пакета с функциями для научных вычислений NumPy (http://www.numpy.org/) и библиотеки для анализа данных Pandas (http://pandas.pydata.org/). Также теперь работоспособны и многие другие Python-модули, использующие вставки на C-API;- Поддержка интеграции с компилятором Cython 0.27.1 (https://www.opennet.ru/opennews/art.shtml?num=47307), совместное использование которого с PyPy позволяет существенно расширить поддержки Python-проектов, использующих C-API;
- Проведена оптимизация парсера JSON для увеличения скорости работы с повторяющимися строковыми ключами и сокращения потребления памяти. Для крупных JSON-файлов c повторяющимися ключами отмечается до 50% сокращение потребления памяти и до 15% ускорение разбора.
- До версии 1.11.1 обновлён модуль CFFI (https://cffi.readthedocs.org/en/latest/) (C Foreign Function Interface) с реализацией интерфейса для вызова функций, написанных на языке Си, который может выступать в качестве более простой альтернативы модулю ctypes (http://python.net/crew/theller/ctypes/). В новой версии добавлена поддержка сложных аргументов в режиме API, а также типов char16_t и char32_t, улучшена поддержка callback-вызовов.
- Решены многие проблемы с обвязке для C-API, приводящие к излишнему потреблению памяти и несовместимостям.
URL: https://morepypy.blogspot.ru/2017/10/pypy-v59-released-now-s...
Новость: http://www.opennet.ru/opennews/art.shtml?num=47340
А, что реально быстрее PyPy или Nutka, если надо питотячию портянку побыстрее выполнить? У кого-нибудь есть опыт или обширные тесты по этой проблеме?
https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=nu...
> если надо питотячию портянку побыстрее выполнить?перепишите на go, все так делают
Ага, сейчас и растоманы подтянутся.
https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-...не надо вообще нигде питон использовать. См. на диаграмму ошибок...
+1000
Гитхаб же...
Ну и плюс глядя на диаграмму я могу сказать cто не надо использовать C,C++ и PHP,
а самый божественный язык это ... JS. И да, много буков, никто не будет это читать.
Попытался сходить по ссылке. В результатеApplication error
Change this error message for exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) in public/500.htmlЭто всё из-за Python наверное, вот подлец то какой......
> https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-...
> не надо вообще нигде питон использовать. См. на диаграмму ошибок...Судя по Вашей ссылке, с питоном как раз все хорошо, в отличие от c/c++.
Huitka быстрее, оно компиляется в СиСи
> Huitka быстрее, оно компиляется в СиСиЭто конечно аргУмент. Правда, можно и брейнфак в си компилировать, однако, бывалые ОЙтишники бают, что не умеют ЦПУ пока что сишку напрямки читать ... врут наверное.
Учитывая, что сабж может через трейсинг хоть как-то "вычислить" реально используемые типы и сгенерировать (благо, JIT) код под них, тогда как Nuitke для такого же результата придется подтянуть плагин "Оракул 2.0" и подключиться к /dev/crystalball -- очень сомнительно.
Писали бы на LISP/Haskell/Clojure и не выеживались. Вам сами боги дали божественный ((((())))) - синтаксис. А вы! Ээх!
> Писали бы на LISP/Haskell/Clojure
>божественный ((((())))) - синтаксис...кто-то что-то не знает про хаскаль? Не я, надкюсь.
$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> ((((()))))
()Это все, что вы боялись, али еще есть?
Но надо признать, идеи, лежащие в основе CL, очень хороши.
Какие такие идеи?
Смайлики. Лиспо-листинги улыбаются программисту. И программист улыбается листингам.
И все счастливы
> Смайлики. Лиспо-листинги улыбаются программисту. И программист улыбается листингам.А листинги питона - это боль и страдания
Хотите прод пример применения pypy - пожалуйста. На pypy graphite (если быть точным его writers) работают на порядок(!) быстрее CPython. Есть конечно недостаток - потребление памяти почти в 2 раза больше, но этот размен стоит того.
Тут речь не о pypy vs CPython, а смысле дальнейшего существования Python вообще. Гугл пытался исправить ситуацию, но не получилось. Теперь мнение мирового сообщества склоняется к отказу от данного языка в пользу другого., по большей части задач к Go. Ну и зачем, спрашивается, его теребить дальше, если уже всё решили...
Фантазёры - они такие. Python перестают использовать только в сетевых сервисах, где он изначально был странным выбором. Почему выбор сделан в пользу убогого Go - непонятно.
У Go с самого старта всё в порядке. От убогости Python пыталась излечить сама google. Но убогость Python'а - это его суть. С этим ничего не сделать.
Особенно с net.http.client, да. Кто ходил по граблям тот знает.
> мнение мирового сообщества
> уже всё решилиРазговоры с голосами в голове вряд ли можно считать весомыми аргументами. Язык (любой) будет существовать ровно столько, сколько в нем будет потребности. Для Python она есть, и весьма сомнительно, что ее от токсичных комментариев на опеннете поубавится.
Безусловно, Вы правы. Извращенцы в обществе были всегда, с чего вдруг им исчезнуть!
> Язык (любой) будет существовать ровно столько, сколько в нем будет потребностиНе обязательно. Есть такие языки, нужность которых как таковых сама по себе, мягко говоря, сомнительна, но некоторые нужные вещи на столько срослись с ними, что заменять их (языки) "in-place" на более адекватные кажется невыполнимой задачей. Примеры таких языков - Cobol, VBA и JavaScript.
>Примеры таких языков - Cobol, VBA и JavaScript,Java
Только какой смысл, если есть go-carbon и carbonapi, написанные на Go которые ещё на порядок быстрее чем оригинальный стек на pypy?
А что там насчёт PyPy.js?
> А что там насчёт PyPy.js?Вот же, положила: pyjs.org