Доступен (https://morepypy.blogspot.ru/2016/10/pypy3-550-released.html) выпуск PyPy3 5.5.0 (http://pypy.org/download.html), реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython, Restricted Python). Ветка PyPy3 развивается синхронно с PyPy и отличается поддержкой Python 3. В частности, если выпуск PyPy обеспечивает поддержку языка Python 2.7.10, то PyPy3 предоставляет реализацию Python 3.3.5. Выпуск доступен для Linux (x86, x86_64, PPC64, s390x, ARMv6 или ARMv7 с VFPv3), macOS и Windows.Особенностью PyPy является использование JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, что позволяет обеспечить высокий (http://speed.pypy.org/) уровень производительности - при выполнении некоторых операций PyPy в несколько раз обгоняет классическую реализацию Python на языке Си (CPython). Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
В новой версии проведена работа по улучшению совместимости с веткой Python 3.3 (3.3.5). Добавлена поддержка функций os.get_terminal_size(), time.monotonic(), str.casefold() и модуля faulthandler. В состав включён пакет ensurepip. Улучшен интерфейс для работы с буферами. Внесены улучшения в JIT. Началась работа по поддержке Python 3.5.
URL: https://morepypy.blogspot.ru/2016/10/pypy3-550-released.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=45317
> Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памятиJIT он такой: одно лечит, другое калечит...
Такова природа алгоритмов. Довольно редко бывает, что эффективности можно добиться без использования памяти.
Надеюсь это сказал прожжённый ассемблерщик, знающий как сделать на такт быстрее и на байт меньше.
на самом деле такое бывает часто. Даже бывает наоборот, т.е. нужно уменьшить кол-во используемой памяти чтобы увеличить производительность. И если бы питон не был таким дерьмом внутри, то существовали бы намного более эффективные методы оптимизаций чем JIT.
> И если бы питон не был таким дерьмом внутриРугать работу коллег-сишников жутко непрофессионально. Я почему-то уверен, что в реальной жизни Вы так не поступаете. Сам-то много не-дерьма насоздавал, а? Как насчет пары ссылочек на свои перлы прямо сейчас?
> Ругать работу коллег-сишников жутко непрофессионально.А не си-шников можно? Ох уж эти шовинисты-нравоучители. В наше время рукожопых людей просто необходимо чморить, унижать и всячески демотивировать ибо в противном случае они превращаются в инициативных идиотов и начинают наносить всем вред.
> Я почему-то уверен, что в реальной жизни Вы так не поступаете.
По себе, двуличному шовинисту, судишь?
Что же такого "дерьмового" в синтаксисе Python (ничем принципиально не отличающимся от 100500 других динамических ЯП), что ему заказаны "эффективные методы оптимизаций" (тм), кроме JIT?Кстати, какие именно методы, для самообразования?
> реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython, Restricted Python)Используется питон, которые не совсем питон ...
Почему бы не писать просто про RPython (--- пояснение про RPython и про то, что там вообще-то Сишный бэкэнд, т.е. генерируется сишный код ;) --- ), а то эта копипаста уже года четыре из новости в новость кочует и каждый раз притягивает претендентов на звание Истинного Петросяна, с унылыми^W искрометно-юморными шутками про "питон, который на питоне, который на питоне надо было писать"
Доступен выпуск Python, реализации языка Python, написанной на языке Python (используется статически типизированное подмножество Python).
Go одним словом, только хуже.
Но всё равно лучше питона, да.
Только лучше, вы хотели сказать
...причём на amd64 это Go медленнее PyPy на вот этом https://github.com/famzah/langs-performance простеньком бенчмарке, буквально вчера тестил
Ну как Java в ущерб памяти.
на числах Фибоначчи совсем другие результаты.
В этом бенчмарке достаточно сделать тривиальную оптимизацию заменив s := []int{} на s := make([]int, 0, n/2) и Go выдаст на 25% больше строчек, что как раз равно разнице между ним и pypy в https://github.com/famzah/langs-performance/blob/master/resu...
Если заменить проход по s с помощью range на классический Cишный вариант, то получим еще 10%, а это уже победа. Замечу, что обе эти оптимизации не трогают алгоритм.
ну массив заранее там для многих языков можно выделить, и везде это, естественно, что-то улучшает. nodejs тоже в полтора раза ускоряется с выделением заранее.вопрос в том чтобы честно сравнить, на одинаковых операциях...
То есть ты предлагаешь намеренно неэффективный код на Go сравнить с оптимизациями PyPy? Ну ок, PyPy победил в этой номинации, только не надо из этого делать вывод, что он быстрее Go в реальных задачах.
Было бы хорошо если бы, 3.5, но они наверное не догонят
Тормозной язык переписанный на тормозном языке цитирую "позволяет обеспечить высокий уровень производительности". Вот они - чудеса хакерской маетматики!
Как PyPy в длинной арифметике по сравнению с python?
Примерно также, как и у CPython - они используют умножение Карацубы для bigint с числом цифирь выше некоторого предела. В противном случае - "школьное" умножение O(n**2).Хочите чудес - используйте библиотеки, написанные профи в предмете. Для CPython есть обертка gmpy2 (для GMP). Как у ей с cffi - не знаю.
PS: А не, вот есть уже gmpy_cffi для pypy.