LINUX.ORG.RU

Вышел PyPy 2.0

 , ,


0

6

9 мая вышла версия PyPy 2.0 с кодовым названием «Einstein Sandwich». PyPy — интерпретатор языка Python со встроенным tracing JIT. Основными изменениями по сравнению с PyPy 1.9 являются:

Планируется, что версия 2.0 послужит стабильной базой для более частых релизов (вероятно, для создания действительно быстрых интерпретаторов Ruby и PHP).

Не вошли в официальный анонс, но тоже немаловажны:

И, наконец (я знал, что вы спросите): работа по распараллеливанию PyPy ведется не слишком активно, но есть ветка STM.

Cравнение скорости PyPy и CPython на синтетических бенчмарках

>>> Подробности

★★★★★

Проверено: DoctorSinus ()
Последнее исправление: unfo (всего исправлений: 7)
Ответ на: комментарий от shahid

Да врядли медленнее существующих интерпретаторов. Другое дело, что я не верю, что pypy для Ruby будет чем-то лучше, чем rubinius.

Deleted
()
Ответ на: комментарий от Deleted

Идея та же

Какая «та же»? Rubinius - это LLVM JIT, приспособленный для Ruby; PyPy - реализация Python поверх оригинальной JIT-инфраструктуры.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Никакого отставания — он поддерживает и 2.0. Причем, начал поддерживать еще до стабильного релиза 2.0.

Но все же Rubinius и PyPy — это не совсем одно и то же. Вот здесь хорошо объяснено различие.

Тем не менее, я очень сомневаюсь в том, что будет не академическая польза от проектов topaz и typhon.

Anatolik ★★
()
Ответ на: комментарий от Anatolik

я очень сомневаюсь в том, что будет не академическая польза от проектов topaz и typhon.

От typhon - точно не будет. Даже академической пользы.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Rubinius до жути сырой и пилится одним голландцем и Engine Yard, никакие фейсбуки за ним не стоят, даже на офсайте висит до сих пор 1.2.4 и ни слова о 2.0, хотя 2.0 уже давно в мастер-ветке. Вообще, зря PyPy написан на питоне, не зря ведь HotSpot написан на С++ и считается самым быстрым JVM. Тут Rubinius правильнее будет, используя Си и С++.

Для рубистов кстати хорошая новость: https://bugs.ruby-lang.org/issues/8339

anonymous
()
Ответ на: комментарий от lucentcode

смысла нет, более того, юзкейсов для самомо pypy очень мало

umren ★★★★★
()

Тесты, конечно, красивые, но как у него дела с потреблением оперативки? Жрет, небось, раза в два больше?

anonymous
()
Ответ на: комментарий от anonymous

Любой жит жрет немного больше, чем интерпретатор, но кого это волнует? Лишь бы работал быстро.

Deleted
()
Ответ на: комментарий от Stalin

Потому, что на лоре достаточно любителей руби.

Deleted
()
Ответ на: комментарий от lucentcode

LLVM - это низкоуровневый платформонезависимый байткод, нужен, в основном, чтобы разработчики компиляторов не парились с поддержкой x86, x86-64, arm и всякими оптимизациями на уровне инструкций.

Питоний байткод - высокоуровневый, там нету понятия типа данных, есть только операции. Есть стек, есть таблицы символов. Тип того, что хранится в ячейках этих структур - на этапе компиляции неизвестен и определяется во время исполнения. Задача PyPy - провести статический анализ (type inference) с целью сведения части функций в типизированный код. В общем случае эту задачу решить нельзя, поэтому там, где она решилась (удовлетворяет требованиям RPython) PyPy генерирует типизированный байткод (LLVM, сишный код, или любой другой бекэнд), компилит и исполняет нативно, а там где не получилось - все работает как и в обычном питоне.

snizovtsev ★★★★★
()
Ответ на: комментарий от anonymous

Вы про запятую вместо тире? Я не граммар-наци, поэтому такие мелочи меня мало волнуют. А после слова «прежде» разве не нужна запятая? Насколько я помню уроки русского языка(при том, что я - не русский) - она там обязана быть. Выньте бревно из своего глаза, товарищ. А потом идите учить других.

lucentcode ★★★★★
()
Последнее исправление: lucentcode (всего исправлений: 1)
Ответ на: комментарий от snizovtsev

Понятно. Спасибо за разъяснение. Теперь понятен смысл такого проекта, как PyPy.

lucentcode ★★★★★
()
Ответ на: комментарий от snizovtsev

Задача PyPy - провести статический анализ (type inference) с целью сведения части функций в типизированный код. В общем случае эту задачу решить нельзя, поэтому там, где она решилась (удовлетворяет требованиям RPython) PyPy генерирует типизированный байткод (LLVM, сишный код, или любой другой бекэнд), компилит и исполняет нативно, а там где не получилось - все работает как и в обычном питоне.

Дезинформация.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от snizovtsev

прежде чем сказать, подумайте не чушь ли это

anonymous
()
Ответ на: комментарий от SAA

Ну если заниматься формошлепством и сайтоклепанием

А чем не так стыдно заниматься программисту?

boo32
()
Ответ на: комментарий от lucentcode

Говорят он не прокатывает для динамически типизированных языков, все попытки заюзать его для таких ЯП пока провалились.

Gorthauer ★★★★★
()

Как скоро ждать поддержки третьего питона?

Deleted
()
Ответ на: комментарий от snizovtsev

А что конкретно тебе и анонимусу ниже не нравится сказать нельзя?

Ты пишешь какие-то вещи, которые мало относятся к PyPy или не относятся к нему вообще. Например:

Питоний байткод - высокоуровневый, там [...]

Ну да, примерно так и есть. Ну и что?

Задача PyPy - провести статический анализ (type inference) с целью сведения части функций в типизированный код. В общем случае эту задачу решить нельзя, поэтому там, где она решилась (удовлетворяет требованиям RPython)

Это описание можно было бы притянуть к поведению tracing JIT, но «статический анализ» и упоминание RPython делают его бессмысленным набором слов.

Если кратко, то PyPy - это две вещи: 1) RPython - статически типизируемое (с выводом типов) подмножество Python, транслируемое в Си, и 2) интерпретатор Python, написанный на RPython. Главная магия PyPy - в том, что при трансляции интепретатора, написанного на RPython, _автоматически_ получается интерпретатор с tracing JIT; эта автоматическая генерация JIT-транслятора делает RPython средством для написания интерпретаторов любых динамических языков, а не только Python. Tracing JIT на этапе исполнения динамически анализирует типы данных, обрабатываемые байткодом, запоминает конкретные типы объектов, имеющиеся на входе базовых блоков, и генерирует нативный код, оптимизированный для обнаруженных сочетаниий типов; при обнаружении на входе базового блока известного сочетания типов вместо байткода выполняется нативный код.

Описание является краткой выжимкой статьи Fast Enough VMs in Fast Enough Time, которая крайне рекомендуется к прочтению всем, кого интересует PyPy или tracing JIT в применении к динамическим языкам, и обязательна для прочтения тем, кто пытается объяснять устройство PyPy другим.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от snizovtsev

Это именно что JIT, в смысле — именно после прогона кода (цикла, функции и т.д.) PyPy-jit берётся его оптимизировать под конкретный тип (если, конечно, RPython указывает на такую оптимизацию).

Для этого есть целый зоопарк механизмов указания, будет ли данная переменная постоянна для цикла или будет изменятся в процессе.

davinchi
()

Сравниваю два сегодняшних (на первый взгляд разнородных) сообщения.

1. «Вышел PyPy 2.0» (с)

2. «Сегодня в провинции до половины мужского населения работают охранниками. По сути, это – скрытая безработица.» (с)

Путем дедукции выводим. -> Создание подобных поделий есть форма псевдозанятости для кульхацкеров.

Bioreactor ★★★★★
()
Последнее исправление: Bioreactor (всего исправлений: 1)
Ответ на: комментарий от Gorthauer

Да, он заточен под компилируемые ЯП, вроде C. Но мне кажется, что в скриптах python есть участки кода, которые теоретически можно скомпилировать в код со статической типизацией. И именно эти участки кода компилировать LLVM. То, что не получилось скомпилировать, можно запускать в модифицированном CPython. Проблема в том, как наладить бесшовную работу скомпилированного кода, и запускаемого в интерпретаторе.

lucentcode ★★★★★
()
Ответ на: комментарий от davinchi

davinci

Поправлено.

В итальянском ci читается как «чи» (ciao), chi же — как «ки». Ну и в английский имя перешло без изменений в произношении или написании. Может быть ты, конечно, писал типа в транслите, но это совсем убого.

anonymous
()
Ответ на: комментарий от lucentcode

PyPy эту проблему решил, если что.

А ещё есть numba, nigga.

davinchi
()

И кому он нужен без Python 3?
Позиционировалось как что-то динамичное и гибкое, в отличие от CPython, а не деле всё наоборот. CPython строчит новые версии и вводит новые плюшки, а PyPy остался там же, где и был 5 лет назад

anonymoos ★★★★★
()
Ответ на: комментарий от X-Pilot

проект Parrot.

А что с ним случилось, кстати?

Он сдох - странно было бы ожидать чего-то жизнеспособного от апологетов Perl-6.

alienclaster ★★★
()
Ответ на: комментарий от tailgunner

Ну я примерно так себе все и представлял, вероятно объяснил криво - это в моем стиле.

Пока непонятно только, что такого особого в RPython, что делает его средством написания любых динамических языков. Много общих частей в таких интерпретаторах будет, но все же и различается многое.

За статью спасибо, почитаю.

snizovtsev ★★★★★
()
Ответ на: комментарий от alienclaster

Он сдох - странно было бы ожидать чего-то жизнеспособного от апологетов Perl-6.

Нда. Как-то банально...

X-Pilot ★★★★★
()
Ответ на: комментарий от neuron

Ага, особенно на виртуальных серверах, где за 256 мегабайт нужно 10 баксов в месяц платить.

И вообще, как твою дешевую оперативку в ноутбук вставлять? Если она там впаяна? На макбуках уже так сделали, другие вендоры к тому же идут.

И на тех же ПК тоже не всегда просто можно планку воткнуть. Что если материнка не поддерживает ddr3? Ddr2 память устаревшая и не такая дешевая (т.к. цены заморозились ещё несколько лет назад). Разоряться на материнку, да? А вместе с ней и процессор, ага.

anonymous
()
Ответ на: комментарий от provaton

Им уже кто-то пользуется в продакшене?

Да, PyPy используется в продакшене.

xpahos ★★★★★
()
Ответ на: комментарий от anonymoos

PyPy остался там же, где и был 5 лет назад

Поздравляем вас, гражданин, соврамши.

А что, прозрачная сквозная поддержка юникода там уже есть?

Ну вот, начались отмазки и попытки выдать воображаемые недостатки за отсуствие развития.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Просвети, что есть «прозрачная сквозная» поддержка юникода?

Это когда все строки имеют внутренне представление в юникоде. И нет такого типа как unicode вообще, есть только тип строки.
И если я уже один раз создал строку, то могу её где угодно сохранять, чем угодно обрабатывать и куда угодно отправлять, не думая о такой вещи как кодировка вообще. Такого понятия больше нет в моём коде.

anonymoos ★★★★★
()
Ответ на: комментарий от anonymoos

А, ну, тогда её наличие можно было бы смело считать недостатком.

anonymous
()
Ответ на: комментарий от Binary

А на том конце пусть сами догадываются?

Зачем догадываться? xml-rpc, json-rpc, внутренние кодировки веб-страниц и баз данных, файлы конфигурации... везде utf-8 стандарт де-факто. Чтобы было не так, это надо специально сильно извратиться и откопать из могилы какую-нибудь freebsd (чур меня)

anonymoos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.