The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз PyPy 1.4, реализации Python, написанной на языке Python

28.11.2010 00:07

Представлен релиз проекта PyPy 1.4, в рамках которого разрабатывается реализации языка Python, на нём же написанная. Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си. Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти.

В PyPy также поддерживается бесстековый (Stackless) режим работы, позволяющий добиться массового параллельного выполнения микропотоков (micro-threads). Для выполнения кода, к которому нет доверия, реализован режим изолированного выполнения, отличающегося от sandbox в CPython полной поддержкой всех возможностей языка без выделения unsafe-функций. Дополнительно на базе технологий PyPy созданы бэкенды для генерации в PyPy байткода для LLVM и виртуальных машин .NET/CLI и Java. Отдельно на базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.

При подготовке новой версии проведена большая работа по увеличению производительности, подготовлен 64-разрядный JIT-бэкенд и стабилизирована кодовая база. По заявлению разработчиков, 32- и 64-разрядные версии PyPy уже достаточно стабильны на платформе Linux и готовы для промышленной эксплуатации. Более того, версия PyPy 1.4 является первым релизом, который транслирует самого себя быстрее, чем CPython.

Некоторые особенности релиза PyPy 1.4:

  • Встроенный в PyPy JIT-компилятор генерируется автоматически и полностью прозрачен. Потребление памяти снижено до разумных границ, например, общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза при примерно двухкратном росте производительности выполнения;
  • Экземпляры классов теперь хранятся в более компактном представлении, настолько компактном, как если был они были созданы с атрибутом __slots__, что приводит к значительному снижению расхода памяти;
  • PyPy теперь полностью совместим с пакетом virtualenv, позволяющим создавать собственные виртуальные окружения Python;
  • Ускорена работа регулярных выражений, для оптимизации которых дополнительно задействована JIT-компиляция. Модуль "re" теперь работает значительно быстрее;
  • При вызове многих функций, например, map() теперь используется JIT-компиляция.


  1. Главная ссылка к новости (http://morepypy.blogspot.com/2...)
  2. OpenNews: Проект по интеграции поддержки многопоточности в Python и релиз PyPy 1.3
  3. OpenNews: Релиз PyPy 1.2, реализации Python, написанной на языке Python
  4. OpenNews: Разработчики Google задались целью сделать Python интерпретатор в 5 раз быстрее
  5. OpenNews: Unladen Swallow - новая реализация интерпретатора Python на базе LLVM
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/28810-PyPy
Ключевые слова: PyPy, python, jit
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Tav (ok), 01:17, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    График — какая-то дурацкая расческа из единичных столбиков. Если уж изображать относительную производительность, то как-то так: http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben=1,2,3,4,5,
     
     
  • 2.3, Аноним (-), 02:00, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не просто расческа, там даже на 1.0 тика и линии нет. Не верю, что люди, которые не могут нормально график нарисовать, могут написать эффективную реализацию питона.
     
     
  • 3.4, Aquarius (ok), 02:20, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Не просто расческа, там даже на 1.0 тика и линии нет. Не
    > верю, что люди, которые не могут нормально график нарисовать, могут написать
    > эффективную реализацию питона.

    это не график, а именно диаграмма (прочитайте подписи) и не может быть графиком - столбцы не имеют естественного порядка кроме алфавитного по подписям

     
     
  • 4.5, Аноним (-), 02:35, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • –16 +/
    Нет никакогй разницы как это называется, важно что это сделано абсолютно безграмотно.
     
     
  • 5.30, igron (ok), 01:24, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты адекватен? Картинка абсолютна нормальная.
     

  • 1.2, dq0s4y71 (??), 01:44, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Отдельно на базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.

    http://codespeak.net/svn/pypy/lang/prolog/trunk/prolog/doc.txt

    "Its speed is still quite a bit below that of highly optimized Prologs,
    roughly 10-100 times slower than 'Sicstus Prolog'_."

    М-да... Можно гланды удалять через задний проход, а можно и компиляторы писать на Питоне :)

     
     
  • 2.19, ы (?), 18:39, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А еще можно компиляторы от интерпретаторов не отличать и из тестовых опытов по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.  
     
     
  • 3.23, dq0s4y71 (??), 20:31, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А еще можно компиляторы от интерпретаторов не отличать

    Можно и не отличать. Только в данном случае речь идет именно о (JIT) компиляторе.

    > и из тестовых опытов
    > по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.

    А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)

     
     
  • 4.29, ы (?), 00:24, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> А еще можно компиляторы от интерпретаторов не отличать
    > Можно и не отличать. Только в данном случае речь идет именно о
    > (JIT) компиляторе.

    Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова про JIT там нет. Уже сама постановка такой задачи подразумевает возможность почти неограниченной оптимизации, и первичный тестовый код вообще не может рассматриваться как нечто неизменное, тем более результаты тестирования быстродействия.

    Хотя сам pypy конечно использует JIT и он полноценный в отличии от урезанного в CPython, также добавлю что первоначальная реализация pypy также в разы проигрывала по скорости CPython, сейчас как видно на графике, большинство тестов на pypy выполняется в разы быстрее и это конечно не предел.

    >> и из тестовых опытов
    >> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
    > А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)

    А они существуют? Хотя конечно в python можно вставлять инструкции и на С и на Assembler, что позволяет создать компилятор на python, но создание исполняемых бинарников не входит в область применения этого языка и задачи им решаемые.

     
     
  • 5.53, dq0s4y71 (??), 15:44, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова
    > про JIT там нет.

    Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."

    >>> и из тестовых опытов
    >>> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
    >> А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
    > А они существуют?

    Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может, то, наверное, какие-то НЕ "сторонние" может? :)

    > Хотя конечно в python можно вставлять инструкции и на
    > С и на Assembler, что позволяет создать компилятор на python, но
    > создание исполняемых бинарников не входит в область применения этого языка и
    > задачи им решаемые.

    Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на
    С и на Assembler.

    Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы. Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие. Так что единственное его достоинство - это то, что на нем можно писать быстро. :)

     
     
  • 6.55, ы (?), 17:09, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."

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

    >Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может,

    Привет, приплыли, я такого не говорил. Читать читать и еще раз читать вникая в каждое слово.

    >Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на

    С и на Assembler.

    Можно, но не удобно.

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

    Можно, но не удобно.

    >Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие.

    Ни одной реализации не существует. С чего вы сделали вывод?

     

  • 1.6, тоже Аноним (ok), 10:08, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что-то мне подсказывает, что если взять Сишную реализацию питона и оптимизировать ее с установкой "можно жрать больше памяти", то прирост будет не только в "некоторых операциях". Да и лишних тормозов в остальных операциях не возникнет.
     
     
  • 2.7, Аноним (-), 10:43, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нет.
     
  • 2.9, Deepwalker (??), 11:12, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Учить матчасть, казаться не будет.
     
     
  • 3.11, тоже Аноним (ok), 11:29, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.
     
     
  • 4.20, ы (?), 18:42, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые
    > азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.

    Вы что нибудь про Just-in-time compilation слышали?

     
     
  • 5.22, тоже Аноним (ok), 20:16, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто ж не слышал. JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых. Чтобы обгоняли - что-то не слышал...
     
     
  • 6.26, ы (?), 23:56, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Отлично, теперь вы можете понять почему интерпретатор на python будет обгонять сишную реализацию, не считая конечно реализацию unladen-swallow.
     
     
  • 7.33, тоже Аноним (ok), 08:52, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Думаю, тут требуются некоторые подробности. Для начала - данные, где реально показывался бы обгон. "Некоторые операции" рассматривать смысла нет, пока в целом реализация заметно тормознее и прожорливее. Я верю, что есть операции, где язык более высокого уровня позволяет меньше "гонять порожняк", чем универсальная реализация на С. Но это просто оптимизация нескольких узких мест, немного смягчающая общее падение производительности.
     
     
  • 8.42, ы (?), 09:18, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Но этож полный здец, график приведен вверху ... текст свёрнут, показать
     
     
  • 9.43, тоже Аноним (ok), 09:35, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    На этом графике показан обгон в трех тестах из двадцати и провал в остальных Ка... текст свёрнут, показать
     
     
  • 10.45, Sergey722 (?), 10:47, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чукча не читатель Да там английским по белому написано рядом с осью относите... текст свёрнут, показать
     
     
  • 11.47, тоже Аноним (ok), 11:09, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Тут пардон, об ся Но для меня лично это больше говорит о проблемах CPython,... текст свёрнут, показать
     
     
  • 12.48, ы (?), 13:49, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, плюс, сюрприз, полный jit... текст свёрнут, показать
     
  • 10.50, ы (?), 14:13, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я таки думаю нужно вам кофейку попить, чтобы правильно понимать графическую инфо... текст свёрнут, показать
     
     
  • 11.52, тоже Аноним (ok), 15:19, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кофейку - обязательно А вот вопрос я бы не закрывал, пока не увидел такой же гр... текст свёрнут, показать
     
     
  • 12.54, ы (?), 16:44, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Извиняйте, и еще раз график вверху, синеньким это CPython Прошу прощения, но да... текст свёрнут, показать
     
     
  • 13.57, тоже Аноним (ok), 19:19, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ваши объяснения ограничиваются одной аббревиатурой, продолжать действительно б... текст свёрнут, показать
     
  • 12.56, userd (ok), 19:08, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Может быть можно Может быть нельзя Пальцем ткните - какие основные алгоритмы в... текст свёрнут, показать
     
     
  • 13.58, тоже Аноним (ok), 19:53, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я, пожалуй, закончу спор, согласившись с оппонентами Сравнение CPython с PyPy -... текст свёрнут, показать
     
     
  • 14.59, ы (?), 21:44, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, цельный гугл над этим работает и ничего сделать не может Блин Сил уже н... текст свёрнут, показать
     
     
  • 15.60, тоже Аноним (ok), 23:55, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ладно, не использует Использует свой, с аттракционами, способ выполнения Python... текст свёрнут, показать
     
  • 6.39, Аноним123321 (ok), 14:46, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых ...

    хотите сказать что преобразование инструкций в машинный код (во время обработки интерпретируемой программы) -- это костыли?

    ...ну тогда с таким же успехом можно сказать что и "Архитектура фон Неймана" вычислительных машин -- это тоже костыли (в отличии от "Гарвардской архитектуры" вычислительных машин)

    :-)

     
     
  • 7.40, тоже Аноним (ok), 16:42, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    JIT, в принципе, делает то же самое, что и С-компилятор, только не один раз при создании программы, а каждый раз при ее работе. Появился JIT именно из-за того, что чистая интерпретация тормозит невыносимо. И это не костыль? Еще скажите, что замыкания - это не глюк сборщика мусора, возведенный в принцип ;)
     
     
  • 8.44, ы (?), 09:49, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А вот и нет Каждый раз не требуется, если конечно код не меняется, а вот время ... текст свёрнут, показать
     
     
  • 9.46, тоже Аноним (ok), 11:05, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это не плюсы JIT, это плюсы интерпретируемого языка С обычной платой за это - п... текст свёрнут, показать
     
     
  • 10.49, ы (?), 13:53, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь представь КИС корпоративную информационную систему , чье внедрение зан... текст свёрнут, показать
     
  • 10.51, ы (?), 14:16, 30/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что python это инерпретируемый язык, и оптимизацией его байт-кода под кон... текст свёрнут, показать
     
  • 3.16, Аноним (-), 15:19, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Где вы вообще в данной теме матчасть нашли?
     

  • 1.8, stimpack (?), 11:01, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    судя по "расческе", как ее тут окрестили, против природы все же не попрешь. Памяти стабильно жрет в два раза больше, а общая желтая полоска явно короче общей синей. Накладные расходы дают о себе знать.
    Но сама новость в позитивных тонах :)
     
  • 1.15, Alexey (??), 14:27, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жаль не поддерживается psycopg2
     
  • 1.17, testeruser (?), 17:06, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а на чем написан питон, на котором написана эта реализация питона?
     
     
  • 2.18, Аноним (-), 18:03, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На питоне!

    BA-DA-TUM-TSSS...

     
     
  • 3.21, Pilat (ok), 19:08, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну и что, Delphi писали на Delphi, C++ на С++
     
     
  • 4.24, тоже Аноним (ok), 20:39, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" из лишнего кода вокруг того, что действительно надо сделать в конкретном случае.
    Оптимизирующий компилятор может бороться с этой регрессией, но в случае интерпретируемых языков его нет...
     
     
  • 5.25, Аноним (-), 22:39, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Python же умеет компилировать в ".pyc" файлы. Может быть когда-нибудь...
     
     
  • 6.31, igron (ok), 01:25, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это не компиляция, а просто удаление лишнего, комментариев и т.п.
     
     
  • 7.35, userd (ok), 11:15, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Однако, преобразование исходного текста программы в байткод стековой виртуальной машины - это вполне компиляция.
     
     
  • 8.37, тоже Аноним (ok), 13:52, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В моем посте ключевое слово - не компилятор , а оптимизирующий ... текст свёрнут, показать
     
  • 5.38, Аноним123321 (ok), 14:38, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" ...

    жесть! ну и анекдот :DDDDDDDD

    ...а на чём же ещё можно написать программу (в том числе интерпретатор-или-компилятор) -- КРОМЕ как на языке программирования?

    ...неужто на Волшебной Мане? :-D

    когда пишешь <чтото> на Волшебной Мане -- то "обёртки" -- не растут? :-)

     
     
  • 6.41, тоже Аноним (ok), 16:46, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А вы не в курсе, что любой язык программирования высокого уровня - это обертка над машинным кодом, позволяющая оперировать более сложными сущностями и не взорвать мозг?
    Причем чем выше уровень языка, тем больше в этих обертках "мусора", помогающего создать более или менее универсальную абстракцию ценой выполнения лишних команд и использования лишней памяти.
     

  • 1.36, Zenitur (?), 13:47, 29/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Компилирую последний nasm (libvpx попросил). Смотрю на процесс - а он на Си. Жду nasmnasm.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру