Опубликован (https://morepypy.blogspot.com/2019/02/pypy-v700-triple-relea...) релиз проекта PyPy 7.0 (http://pypy.org/), в рамках которого развивается реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython (http://doc.pypy.org/en/latest/coding-guide.html#id1), Restricted Python). Выпуск подготовлен одновременно для веток PyPy2.7, PyPy3.5 и PyPy3.6 (альфа-версия), обеспечивающих поддержку синтаксиса Python 2.7, Python 3.5 и Python 3.6. Выпуск доступен для Linux (x86, x86_64, PPC64, s390x, ARMv6 или ARMv7 с VFPv3), macOS (x86_64), OpenBSD, FreeBSD и Windows (x86).
Особенностью PyPy является использование JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, что позволяет обеспечить высокий (http://speed.pypy.org/) уровень производительности - при выполнении некоторых операций PyPy в несколько раз обгоняет классическую реализацию Python на языке Си (CPython). Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
В новом выпуске (http://doc.pypy.org/en/latest/release-v7.0.0.html):
- Представлен первый альфа-выпуск новой ветки PyPy3.6, предоставляющей поддержку Python 3.6;
- Добавлена возможность подключения обработчиков к сборщику мусора (GC hooks (https://morepypy.blogspot.com/2019/01/pypy-for-low-latency-s...)), позволяющих на низком уровне управлять поведением сборщика мусора, отключая его в моменты, требующие предсказуемой производительности или отсутствия задержек. Следует иметь в виду, что при отключении сборки мусора может наблюдаться неконтролируемый рост потребления памяти. Управление производится при помощи двух функций: gc.disable() для отключения автоматического сборщика мусора и gc.collect_step() для ручного выполнения отдельных шагов для сборки мусора;- Обновлены модули CFFI 1.12 (C Foreign Function Interface) и cppyy 1.4 с реализацией интерфейса для вызова функций, написанных на языках Си и C++. В ветках Py3.5 и Py3.6 появилась поддержка cppyy, ранее доступного только в PyPy2.7;
- Реализованы специфичные для Python 3.6 функции и объекты Py_ReprEnter, Py_ReprLeave(), PyMarshal_ReadObjectFromString, PyMarshal_WriteObjectToString, PyObject_DelItemString, PyMapping_DelItem, PyMapping_DelItemString, PyEval_GetFrame, PyOS_InputHook, PyErr_FormatFromCause, __set_name__, __init_subclass__;
- В основную ветку PyPy переведена разработка отладчика revdb (https://bitbucket.org/pypy/revdb) с поддержкой отладки с возвратом к более ранним состояниям (reverse debugging);
- Добавлена поддержка платформы GNU Hurd. Улучшена работа в окружении
FreeBSD (в том числе теперь работоспособна система профилирования vmprof (https://vmprof.readthedocs.io/en/latest/));
- Код для перевода внутреннего представления строк на utf8 не вошёл в релиз.
URL: https://morepypy.blogspot.com/2019/02/pypy-v700-triple-relea...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50132
Скажите, в этой реализации тоже есть GIL?
Да есть пользуйся не бойся
Тогда я не очень понимаю смысл этого прожекта. Переписать на питоне просто чтобы переписать на питоне?
> Тогда я не очень понимаю смысл этого прожекта. Переписать на питоне просто чтобы переписать на питоне?А пройти по ссылке и прочитать не позволяют религиозные убеждения?
> PyPy is a replacement for CPython. It is built using the RPython language that was co-developed with it. The main reason to use it instead of CPython is speed: it runs generally faster (see next section).
> Speed
> Our main executable comes with a Just-in-Time compiler. It is really fast in running most benchmarks – including very large and complicated Python applications, not just 10-liners....
> Speed: thanks to its Just-in-Time compiler, Python programs often run faster on PyPy. (What is a JIT compiler?)
> “If you want your code to run faster, you should probably just use PyPy.” — Guido van Rossum (creator of Python)
> Memory usage: memory-hungry Python programs (several hundreds of MBs or more) might end up taking less space than they do in CPython.
> Stackless: PyPy comes by default with support for stackless mode, providing micro-threads for massive concurrency.
>
ну казалось бы оно работает быстрее не потому что переписано на питоне а потому что есть jit. почему нельзя было например форкнуть cpython и добавить jit туда? ну или если не устраивает именно С, использовать какой-нибудь другой компилируемый язык?
> почему нельзя было например форкнуть cpython и добавить jit туда?Можно. Гугловский Unladen Swallow был именно форком CPython.
PySton был на плюсах и спонсировался дропбоксом. Про psyco (JIT на Си, вроде бы с генерацией машинного кода - не помню уже) или nuitka (транслятор в c++) упоминать не буду.
> ну или если не устраивает именно С, использовать какой-нибудь другой компилируемый язык?еОчевидно, посчитали что проще писать JIT на RPython, который после оптимизаций, транслируется в Си, чем писать JIT на Си:
https://rpython.readthedocs.io/en/latest/architecture.html
> Goals and Architecture Overview
> High Level Goals
> Traditionally, language interpreters are written in a target platform language such as C/Posix, Java or C#.
> ...
> PyPy is experimenting with a more ambitious approach. We are using a subset of the high-level language Python, called RPython Language, in which we write languages as simple interpreters with few references
>Оно конечно опеннетчикам виднее, что и как лучше, но вот то, что гугл и дропбокс прикрыли свои форки, так и недобившись цели, а PyPy все еще относительно бодр и жив …
https://www.opennet.dev/opennews/art.shtml?num=45984
> 05.02.2017 10:55 Dropbox прекращает разработку Pyston. Опубликован финальный выпуск 0.6.1https://www.opennet.dev/opennews/art.shtml?num=20981
> 28.03.2009 12:23 Разработчики Google задались целью сделать Python интерпретатор в 5 раз быстрее.
> но вот то, что гугл и дропбокс прикрыли свои форки, так и недобившись цели, а PyPy все еще относительно бодр и жив …Золотые слова!
GraalVM пошел тем же путем, но вместо Python взяли Java.
Думаю, в перспективе GraalVM, как фреймворк для построения JIT компиляторов, получит большее распространение. Всё-таки, и поддержка многопоточности из коробки имеется, и опыт в сборщиках мусора намного больше. А еще мне кажется, что модель автоматической генерации jit компилятора из интерпретатора AST дерева имеет большую гибкость, чем из интерпретатора байткода (как в PyPy).
Но, как бы то ни было, PyPy навсегда останутся в истории как те, кто первыми доказал, что игра стоит свеч.
ты хоть понимаешь смысл GIL?
ты хоть понимаешь смысл GIL?
> Конечно! Чтобы тормозить?
> ты хоть понимаешь смысл GIL?
>> Конечно! Чтобы не парится с синхронизацией и убыстрять однопоточники отсутсвием оверхеда с локами и прочимОх уж эти понимальщики опеннета. Поправил, не благодари.
Python версии 3.7, а у этих уже свой путь и более лучшая нумерация версий - 7.0.
Там не так много фич и большинство пакетов с 3.5 еще работают.
Да и воообще в Debian Stretch в репах именго 3.5, и они не парятся, pip работает.
Ннада еще реализацию JS на JS, чтобы был... Так стоп...
??? nodejs is JIT вообще то...
> ??? nodejs is JIT вообще то...Но не на JS или его подмножестве. Хотя оно и понятно - писать JIT чутка сложнее, чем редактор или плеер на электроне.
> Добавлена поддержка платформы GNU Hurd.Оч. нужная платформа.
C++ и ASM - лучшая связка. Остальное - от лукавого!
тогда уж чистый си )) наковыряли в плюсах столько что аж страшно)) сделай прогу на си и оберни её на питоне не будет медленнее))
Скорее, прогу на Питоне. Там же есть классы и всё такое, а отдельные критичные методы на C.
уж лучше сделай прогу на си. сделать всё что требует топорной работы на C а потом сложную прикладную логику (которай на C будет недоставать количество всяких структур и сборки мусора) заэмбедить на Python
Лучше прикладную работу на С++, а топорную на ASM - это даёт высокую производительность, хорошую гибкость и большие возможности по дальнейшему увеличению производительности без ущерба для гибкости. Другие связки ничего близкого по балансу производительности и гибкости не дают.
>C++ и ASM - лучшая связка. Остальное - от лукавого!Достоверно известно, что требование "чтобы программа ела мало ОЗУ и быстро работала" не попадает в TOP5 (требований) ни у бизнеса, ни у фофанов. Так что лукавым лукавое.
> Достоверно известно, что требование "чтобы программа ела мало ОЗУ и быстро работала" не попадает в TOP5 (требований) ни у бизнеса, ни у фофановдостоверно известно что 99% дерьма которое создаёт бизнес (особенно в плане софта) -- не нужно
Только я бы сказал "псевдобизнес". Бизнес, как ни странно, достаточно много книмания уделяет скорости работы.
>Только я бы сказал "псевдобизнес".Сказал А, говори Б. Список труъ бизнесов, у которых сайт сделан на ASM (ну или ОК, ansi c).
ERP аналогично, не проклятый сплошь жабовый SAPик, а труъ сишный ERP.
ТОП 5 бизнесов, где ОС сделана на javascript
Сайты частично сделаны на ASM, и браузеры тоже! На ASM пишутся критически важные по производительности, расходу памяти, часто задействуемые части программы, то, что проще сделать на ASM, чем на чём-то другом (открытие?! да, такое случается чаще, чем многие думают!), и то, что другими средствами сделать невозможно, а не всё подряд :)
>Сайты частично сделаны на ASM, и браузеры тоже!Давай пойдём дальше в твоем передергивании. В питоне многое написано на си (а может и на ассемблере). Вообще говоря JVM написана на си+асм.
Итого: ойвсё, любая прога написана на асме.
JVM придумали, чтобы куча неопытных "индусов" смогла клепать хоть какой-то через ж-пу работающий код, т.к. С++ требует аккуратности и понимания, что вы делаете, зачем и какие возможности языка уместно применять в конкретном случае, а какие приведут к потери производительности и распуханию программы. Естественно, для эффективного применения С++ надо понимать, в какие примерно машинные инструкции преобразуется ваш код и как будут организованы данные в памяти, чтобы код оставался эффективен. Т.е. вы можете кодировать на С++, как на Java или другом языке высокого уровня, но преимущества С++ раскрываются при понимании, как работает железо и, при необходимости, дозированном использовании ASM, если вы строите высокопроизводительные системы.В С++ есть гораздо больше интересных вещей, чем предоставляет любая JVM, плюс в некоторых компиляторах С++ возможность тесной связки с ASM, которой нет и не может быть в языках на JVM, т.е. сравнимого сочетания производительности и гибкости другими средствами, кроме как сочетанием С++ и ASM вы не получите, как не старайтесь, и разница в производительности будет как минимум на порядок. Поэтому там, где программы на C++ и ASM работают на дохлом железе, в иных случаях строят дата-центры, чтобы вся эта телега хоть как-то работала.
И помните! Процессор - это аппаратная "JVM", которую нужно умело использовать, а не убивать её возможности программными прослойками в виде других JVM!
> т.к. С++ требует аккуратности и понимания, что вы делаетеЕсли вы используете C++, а не C - то вы уже натурально что-то не понимаете.
> В С++ есть гораздо больше интересных вещей, чем предоставляет любая JVM
Да уш... Прям как в поделии д-ра Франкенштейна.
С есть подмножество С++, т.е. С++ - это С кучей примочек. Например, какой смысл изобретать на С ООП, если оно есть в С++? Или почему бы не использовать более удобные средства вывода С++ на консоль? Компиляторы С и С++ используются одни и те же. Эффективность одна и та же и в плане производительности, и в плане расхода памяти. Если вас какие-то инструменты С++ не устраивают - не используйте - делов то!
> С есть подмножество С++, т.е. С++ - это С кучей примочек.Именно! Куча ...
> Например, какой смысл изобретать на С ООП, если оно есть в С++?
Какой смысл не есть какашки?
> Или почему бы не использовать более удобные средства вывода С++ на
> консоль?Кто вам сказал, что изнасиловав оператор сдвига C++ сделал "более удобный вывод на консоль"?
"Если вас какие-то инструменты С++ не устраивают - не используйте - делов то!"
Меня не устраивает сама необходимость ковыряться в этой куче... инструментов, чтобы выковыривать оттуда жемчужины^Wнекоторые. Зачем, когда есть C? А если нужно что-то более высокоуровневое - вон, есть тот же питон.
Только вот много ли вы сделаете на С без возможностей С++, STL, Boost, Qt и прочих библиотек С++ :) Вы можете, конечно, велосипедить и извращаться... Мы же вам не запрещаем, а как раз наоборот, поддерживаем личный выбор каждого! Более того, может, вы программируете микроконтроллеры? В таком случае С++ вам действительно ни к чему.
> Только вот много ли вы сделаете на С без возможностей С++Ядро операционной системы (тьмы их), конпилятор(ы) C++, текстовый редактор Emacs, стопицот игр, вышеизложенные CPython и PyPy... Кругом одни извращенцы!
Для тех, кто только что из криокамеры... Читаем Википедию: "До версии 4.7.2 GCC был почти полностью написан на Си, хотя значительная часть front-end для Ады написана на Аде. С 14 августа 2012 года разработка была переведена на язык C++[7], версия 4.8[8] и более поздние требуют для своей сборки наличия C++ компилятора, поддерживающего С++ 2003."
Надеюсь, вы не будете возражать, что Clang/LLVM тоже на С++. А Emacs написан был в самом начале компьютерной эпохи, когда и С++ ещё не было отродясь.
Кроме шланга и gcc (до которого тоже добрались хипстеры) - канпиляторов нету, кто б сомневался...
Есть ещё Intel C++, всё остальное в сравнении с Intel C++, GCC и немножечко Clang по возможностям и качеству генерируемого кода для x86-64, к сожалению, шлак, включая Visual C++, который в сравнении с остальными поделками ещё сносно смотрится. Компиляторы для ARM - это совсем другая история.В будущем просьба приводить аргументы и доказательства, а не голословные утверждения, а то людям печально читать бессодержательный текст.
> Есть ещё Intel C++Да на самом деле есть еще до**** всего. Но хоть не заявляешь сходу, что интеловский канпилятор написан на C++, уже прогресс.
> В будущем просьба приводить аргументы и доказательства
Доказательства чего? Наличия массы компиляторов чего угодно, написанных на C?
Давайте, просветите нас, назовав хоть одно наименование :) Мы не будем считать это рекламой :)
> Давайте, просветите насЗачем мне это?
Ядро ОС слишком маленькое, поэтому проблем с написанием их на ASM и/или C особых нет. Проблемы начинаются в крупных проектах, где С++ предоставляет много удобств для профессионалов aka проблем для неосиляторов.
>Ядро ОС слишком маленькое, поэтому проблем с написанием их на ASM и/или C особых нет. Проблемы начинаются в крупных проектах, где С++ предоставляет много удобств для профессионалов aka проблем для неосиляторов.Если ты розовые очки снимешь, то увидишь, что проекты ещё крупнее пилят на жабке, да той самой что "для индусов".
У сишников комплексы от того, что индус со стажем 3 года решает те же задачи, что бородатый сишник-профи со знанием матана. Причём у индуса получается быстрее в разы, а разницу в производительности (1.5-3 раза) легко решают накинув ещё железа. В итоге задача решается быстрее и дешевле. Вывод: сишники не нужны (почти нигде).
Жабисты понабежали :) Ну о чём с ними говорить! :)
Специально для прожжённых жабистов: Фокус в том, что программеры на C++ и ASM генерят решения на порядки эффективнее толпы "индусов", не требующие миллионов строк кода и работающие на слабом железе, поэтому толпа кодеров не нужна вовсе :) Кодерам платят за объём кода или затраченное время, а профессиональному программеру нужны эффективные решения под собственный бизнес. Либо работаете мозгами, либо шевелите руками/ногами/пальцами :)
> Фокус в том, что программеры на C++ и
> ASM генерят решения на порядки эффективнее толпы "индусов""Программеры на C++" сами являются "индусами" (и в переносном, и в прямом),
чуть менее чем все. Так что "генерить решения" эффективнее - не
могут просто по определению.
Ещё один гений, не дочитавший предложение :)
Дак это не сишник. Сишникам с индусами как бы и нечего делить - это разные ниши.
В Python итак много сишного и сишных библ, поэтому ускорять с помощью С/плюсов - особо нечего. Эдак где-то в 2005-х в Инете массово лишнего "перетрепались" о GIL/JIT-тормозах и якобы врожденной "тормознутости" Питона, - вот и кажется ещё кому-то что он тормозной.На самом деле - нет, он теперь стал (с 2.3) - быстрее сам себя раза в 4-е, а с учетом роста мощи железа - во все 10 раз. А вот сишные программы как тогда выполнялись в 1,5-2 раза быстрее чем питоновские, так и сейчас. Но кому нужны эти миллисекундыпреимущества? - Правильно, никому, кроме единиц "обзорщиков, тролей, R-щиков" итп, кому успех Питона уже 15 лет как ежегодно портит их предсказания о скорой змеиной смерти.
А он не просто не дохнет, а еще и из всех мыслимых топов ЯП не выкисает, несмотря на острую конкуренцию. И не надо думать что это всё из-за школоты и студоты, ломанувшей в ML и AI. Они вообще, имхо, ни при чем.
Питон на 20 обозреваемых мною фирмах - сам, безо всяких пинков, незаметно стал за 10 лет основным в админ-скриптах (убив VB, PS и Bash), офисных макросах (как обгоняющий VBA/LOBasic в 3-5 раз по скорости, но трудится с ними в связке) и всяких конверторах/обменах одного в другое (за счет скорости разработки, т.к. всё меняется - формы, форматы, кодировки - с частотой 10 раз в год, техзадания писать дольше, чем перекоживать). Питон для такого перманентного изврата подходит хорошо, потому и становится основным.
Остальное офисное ПО и его базовый функционал - как бы уже написаны и просто должно юзаться.
Два чаю этому господину!Добавлю, что настоящие профессионалы и на C/C++ напишут код, который тормозит. Речь о банальном -- вчерашние студенты упорно читают все данные в память, даже когда этого не нужно
Программу на Python несложно заставить упираться производительностью в io -- выше не прыгнуть
> В Python итак много
>ускорять с помощью С/плюсов - особо нечего.
>о GIL/JIT-тормозах и якобы врожденной "тормознутости" Питона,
> - вот и кажется ещё кому-то что он тормозной.А тем временем в далёкой-далёкой вселенной...
[I]"" In a new blog post, one of Intel's developers outlines some of their performance tweaks to Python for delivering greater performance... "" --http://www.phoronix.com/scan.php?page=news_item&px=Clear-Lin...
> На самом деле - нет, он теперь стал (с 2.3) - быстрее
> сам себя раза в 4-е, а с учетом роста мощи железа
> - во все 10 раз. А вот сишные программы как тогда
Производительности мало не бывает, покуда не изобрели процессор с опкодом "сделай мне зашибись".
Так надо бы на нём браузер написать, раз в 10 раз быстрее стало. А то до сих люди пор люди на сях страдают.
> Так надо бы на нём браузер написать, раз в 10 раз быстрее стало. А то до сих люди пор люди на сях страдают.Страдальцы уже переписали админ-скрипты, офисные макросы, конвертеры и предложили поддержку? Или как обычно, только указываюти и направляют "как правильно"?
> браузер
> на сяхИ где такое чудо (движок, умеющий в современный веб)?
Питон у меня ассоциируется с коболом. Там тоже нужно умело пробелы перед операторами расставлять.
пробелы это не сложно, попробуй
Не, мы лучше на нормальных языках писать будем.
ну уж извини пробелы и скобки необходимые в сях , в питоне не особо нужны( особенно скобки) в привычном для си написании. они там тоже есть, но используются для другого. честно сказать когда взялся за питон первый раз думал придется долго и нудно учить как в сях. а тут раз и на 3 день начал писать прогу по перелопачиванию xml с помощью регулярок. потом попробовал на сях.... поверь кода точно в 2 раза меньше и вылезающие ошибки правятся моментом( тот же интерпретатор сам все объясняет). на сях ... не так просто оказалось. кода больше и отлов багов сложнее. как по скорости. честно не заметил разницы. ну прога была небольшая.
А скорость "по перелопачиванию xml с помощью регулярок" не смутила? Меня бы смутила даже на Сях без регулярок ;)
вы походу никогда не использовали питон. чес слово я специально написал одну и ту же простенькую программку расчета по одной формуле из сапромата. и на глаз разницы не увидел. может быть если замерять спецом и было что то, но так никакой разницы. если писать огромные комбайны на питоне может и есть что то . но нафига мне комбайны. я люблю использовать кучку маленьких прог каждая для своей работы.
myhand одобряет pypy (похоже успели в Buster)больше revdb для народа!
Моя метрика за >0.5k-часов кодинга в VSC:1) Кодинг на JavaScript - 2.7% на печатание {}:()SPACE;
2) Кодинг на Python - 0.06% на печатание {}:()SPACE;А с IntelliSense, автодополнениями и линтерами - итого лучше.
Насчет всяких парсеров xml - об этом писал в 1.28: модули Питона типа re - написаны на сях или чем-то быстром. А библиотеки парсеры - просто написаны на всё, что только может понадобится в жизни (на просто Питоне).
> Моя метрика за >0.5k-часов кодинга в VSC:
> 1) Кодинг на JavaScript - 2.7% на печатание {}:()SPACE;
> 2) Кодинг на Python - 0.06% на печатание {}:()SPACE;С кистевым туннельным синдромом боретесь? Важна каждая скобочка?
https://www.anekdot.ru/id/334092/Или это сравнение пробелов питона со скобочками? 8-0
> А с IntelliSense, автодополнениями и линтерами - итого лучше.Обучаемые бредогенераторы не пробовали?
Кисти не болят только у тех, кто ничего не делает.В VSC "бредогенератор" в IntelliSense встроен с 1.23. Но плюсов особых не дает.
дело говорит. если мы будем рассматривать количество строк кода, то питон явно в выигрыше. сам сравнивал питон и с++ на программе считающей одну и туже формулу. тут вынужден согласиться питон впереди. хотя си мне больше нравится. но когда нужно просто создать такую вот незамысловатую программу расчета или парсер питон будет быстрее. на комбайнах это да си лучше из за скорости.