Comments 94
назвали бы еще PeyPey ^^
интересно было бы на нем джангу запустить
speed.pypy.org/overview/
запускается и в 2.7 раза быстрее…
запускается и в 2.7 раза быстрее…
а к серверу цеплять только через fcgi насколько я понимаю?
Ну по идее это обычный Python. То есть просто вместо python manage.py запускаете pypy manage.py, а уж как Вы там его до этого цепляли — так и цепляйте.
не все так просто — тут уже процитировали, что пока нет поддержки с бинарными модулями(нет API) -т.е. пока нет связки с mod_wsgi и mod_python.
а fcgi имхо не конкурент mod_wsgi, если речь идет о джанге.
а fcgi имхо не конкурент mod_wsgi, если речь идет о джанге.
А не могли вы рассказать, почему fcgi не конкурент mod_wsgi?
в премениости к джанге — fcgi поддержка там не такая хорошая как с mod_wsgi.
так же fcgi имхо управление процессами происходит более громоздко для системы+презапуск сервера при изменении кода.
Вобщем, это немного разные технологии, для разных задач.
так же fcgi имхо управление процессами происходит более громоздко для системы+презапуск сервера при изменении кода.
Вобщем, это немного разные технологии, для разных задач.
Я тоже ппока не понимаю зачем такой саморазворот. Компилятор написать — одно. Компилятор из одного файла делает другой. А вот писать интерпретатор на самом языке… Ни на питоне, ни даже на Java и .NET сборщик мусора для него самого не напишешь. А раз они — на С (C++), то что за баловство? Но пусть будет, мало ли…
Ну а тот факт, что они теперь быстрее в разы, чем интерпретатор на C для Вас не является ответом на вопрос «зачем»?.. (Пока они были в 10 раз медленнее — мне тоже было не понятно зачем этот PyPy нужно вообще делать, но у них был план...)
>> на Java [...] сборщик мусора для него самого не напишешь.
погуглите слова Jikes RVM.
это называется метациклические реализации, они имеют то достоинство, что JIT-компилятор получает возможно оптимизировать внутренности среды исполнения обычно для него недосягаемые…
погуглите слова Jikes RVM.
это называется метациклические реализации, они имеют то достоинство, что JIT-компилятор получает возможно оптимизировать внутренности среды исполнения обычно для него недосягаемые…
aviaconstructor, может быть лучше иногда конструировать самолеты(или чем вы там занимаетесь, судя по нику)?
кроме очевидных плюсов озвученных в топике, PyPy позволяет в разы проще добавлять разные фичи в сам интерепретатор. Реализовать какой-то хак на питоне проще чем на Си — даже перекомпиляции не нужно!
кроме очевидных плюсов озвученных в топике, PyPy позволяет в разы проще добавлять разные фичи в сам интерепретатор. Реализовать какой-то хак на питоне проще чем на Си — даже перекомпиляции не нужно!
Хм… судя по приведенному фрагменту бинарные библиотеки не поддерживаются, следовательно, ну как минимум, общение с БД отсутствует.
RPyC не «какой-то». Он хороший :)
Очень хорошо описано тут:
stackoverflow.com/questions/1410328/what-are-the-pros-and-cons-of-pyro-and-rpyc-python-libs
Если надо — могу перевести на русский.
Сам использовал RPyC для сетевого взаимодействия двух приложений, PYRO не пробовал. На тот момент я не знал о его существовании, а RPyC показался достаточно удобным. Единственным неудобством оказалась необходимость встраивать Python в клиентское приложение, т.к. оно на Delphi. Но и с этим справился.
stackoverflow.com/questions/1410328/what-are-the-pros-and-cons-of-pyro-and-rpyc-python-libs
Если надо — могу перевести на русский.
Сам использовал RPyC для сетевого взаимодействия двух приложений, PYRO не пробовал. На тот момент я не знал о его существовании, а RPyC показался достаточно удобным. Единственным неудобством оказалась необходимость встраивать Python в клиентское приложение, т.к. оно на Delphi. Но и с этим справился.
> В общем, звучит невероятно, но ребята из PyPy изобрели V8 но для Python'а.
Это совсем не V8. Там другой принцип совсем. Трассирующий JIT-компилятор, как в TraceMonkey. А в V8 — обычный. Ну а сама по себе идея JIT-компилятора совсем не нова.
Это совсем не V8. Там другой принцип совсем. Трассирующий JIT-компилятор, как в TraceMonkey. А в V8 — обычный. Ну а сама по себе идея JIT-компилятора совсем не нова.
> но ребята из PyPy изобрели V8 но для Python'а.
Ага, залезли в машину времени, полетели в будущее, вернулись и изобрели >_<
Ну посмотрите на даты то.
Ага, залезли в машину времени, полетели в будущее, вернулись и изобрели >_<
Ну посмотрите на даты то.
Во-первых, PyPy только сейчас обзавелся JIT-компилятором, так что никаких машин времени. V8 вышел года два назад.
Во-вторых, я не имел в виду буквально «изобрели V8», или «стырили идею у V8», или «придумали идею JIT-компиляции», я имел в виду "сделали для Python то же, что V8 сделал для Javascript".
Во-вторых, я не имел в виду буквально «изобрели V8», или «стырили идею у V8», или «придумали идею JIT-компиляции», я имел в виду "сделали для Python то же, что V8 сделал для Javascript".
Вот мне интересно, что в будущем может помешать разработчикам перенести эти же технологии в CPython? Разве нельзя реализовать JIT-компилятор на С?
Одна из задач проекта PyPy как раз и состоит в прототипировании и обкатки идей перед переносом их в стандарт и CPython.
Вроде же предшественник PyPy — Psyco, как раз этим и занимался. Я так и не понял почему автор его бросил.
З.Ы. Если че то сильно ногами не пинайте, я не питонщик, так просто интересуюсь его жизнью :)
З.Ы. Если че то сильно ногами не пинайте, я не питонщик, так просто интересуюсь его жизнью :)
Псико это грязный хак. Там просто дорогостоящие операции заменялись ассемблерными вставками, в результате чего вся математика в разы быстрее работать начинала.
автор перешел на PyPy :)
бросил потому что
1) дальше его развивать уже было некуда, по сути быстрее код он генерить уже не мог
2) у PyPy гораздо больше возможности развиваться, меньше ограничений потому что это изначально исследовательский проект. и писать код на питоне (пусть и урезанном) легче чем на С.
бросил потому что
1) дальше его развивать уже было некуда, по сути быстрее код он генерить уже не мог
2) у PyPy гораздо больше возможности развиваться, меньше ограничений потому что это изначально исследовательский проект. и писать код на питоне (пусть и урезанном) легче чем на С.
PyPy вообще очень глубокая вещь, например одна из задач — трансляция питон-кода в другие языки (например C, вспоминаем хип-хоп пхп)
А зачем вообще сдался JIT? Почему бы всю программу не скомпилировать в машинный код заранее? А?
а еще я не понимаю нафига все вообще пишут на питоне! пусть пишут на Pure C!
Потому что на Си писать неудобно, у него очень уродливый, избыточный и местами двусмысленный синтаксис.
Это у С то двусмысленный синтаксис? В каком месте? И сколько вы программ написали на С, что бы давать хоть какие-то характеристики?
мне кажется он имел ввиду сложность разработки, слежение за памятью, более низким подходом итд =) просто высказался стандартной «дурацкой» фразой
> Это у С то двусмысленный синтаксис? В каком месте?
i++ + i++?
i++ + i++?
по логике i увеличится на один с ложится с самим собой, потом i еще на один увеличится.
p.s.
вы часто такие вещи используете в проектах?
p.s.
вы часто такие вещи используете в проектах?
я что-то не понимаю что двусмысленного в этом синтаксисе? синтаксис тут очень даже однозначный.
возможно вы имели ввиду семантику?
ну так тогда вся прелесть С как раз в таких вещах, именно эти двусмысленности в семантике языка позволяют компиляторам переставлять выражения и ассемблерные инструкции так чтобы процессор мог их бысрее исполнять.
возможно вы имели ввиду семантику?
ну так тогда вся прелесть С как раз в таких вещах, именно эти двусмысленности в семантике языка позволяют компиляторам переставлять выражения и ассемблерные инструкции так чтобы процессор мог их бысрее исполнять.
Это выражение вычисляется по-разному программами собранными разными компиляторами. Если бы вы интересовались миром C/C++ то знали бы, что примерно полтора года назад в рунете была большая драма по поводу как раз таких выражений.
Двусмысленность здесь в том, что это выражение синтаксически корректно, а результат его неопределен.
Двусмысленность здесь в том, что это выражение синтаксически корректно, а результат его неопределен.
Ну хорошо, просто уродливый, чего стоит
> List* l = (List * ) malloc (sizeof(List)*10);
Не многовато ли List'ов?
Также проблемы создают макросы — текст Си очень трудно распарсить/проанализировать внешней программой.
Также, надо постоянно руками писать .h файлы ко всем файлам с кодом, почему я должен делать что-то 2 раза, а? Почему я должен по 100 инклудов в начале писать? И уродливые конструкции вроде #ifndef FILE_H_INCLUDED? И компилятор потом полчаса все это компилирует. Никуда не годится.
Также невозможно работать со строками/массивами/списками, так как в Си нет объектов, а в Си++ они излишне заморочные (надо помнить про порядок вызова конструкторов, прости господи, про 4 вида конструкторов, включая к-тор копирования, все вручную освобождать, и очень много писать текста даже для каких-то простых вещей).
> List* l = (List * ) malloc (sizeof(List)*10);
Не многовато ли List'ов?
Также проблемы создают макросы — текст Си очень трудно распарсить/проанализировать внешней программой.
Также, надо постоянно руками писать .h файлы ко всем файлам с кодом, почему я должен делать что-то 2 раза, а? Почему я должен по 100 инклудов в начале писать? И уродливые конструкции вроде #ifndef FILE_H_INCLUDED? И компилятор потом полчаса все это компилирует. Никуда не годится.
Также невозможно работать со строками/массивами/списками, так как в Си нет объектов, а в Си++ они излишне заморочные (надо помнить про порядок вызова конструкторов, прости господи, про 4 вида конструкторов, включая к-тор копирования, все вручную освобождать, и очень много писать текста даже для каких-то простых вещей).
Вобщем, судя по маразму выше вам хочется чего-то компилируемого, но с хорошим синтаксисом? Дык берите Delphi, Eiffel, Common Lisp, FORTRAN. А вот Eiffel вообще замечательная штука, пишите на его синтаксисе, а получаете код на С.
А вообще, судя по всему, вы очень мало видели С/С++ в тех местах, где они действительно себя проявляют. Ведь вся эта мифическая сложность, которая вам так мешает, нужна для того, что бы контролировать каждый шаг программы, чего вы не сможете сделать на других языках. Не пишите на С декстопные программки, а обратите свой взор хотя бы в область embedded.
И потом не ясно, отчего вам не нравятся шарпы и явы?
А вообще, судя по всему, вы очень мало видели С/С++ в тех местах, где они действительно себя проявляют. Ведь вся эта мифическая сложность, которая вам так мешает, нужна для того, что бы контролировать каждый шаг программы, чего вы не сможете сделать на других языках. Не пишите на С декстопные программки, а обратите свой взор хотя бы в область embedded.
И потом не ясно, отчего вам не нравятся шарпы и явы?
Шарпы и явы тормозят и едят память непомерно.
Синтаксис хороший в Руби и Питоне, так как это относительо новые языки, и в них, видимо учтены потреьности разработчиков (но производительность плачет просто). А горбатиться над каждой буквой, в Си, как наши предки, что-то неохота.
Про Eiffel — почитаю, раньше не слышал.
Есть еще D, но там вроде автор сделал сборку мусора (фиии), и слишком «тяжелые» классы.
Синтаксис хороший в Руби и Питоне, так как это относительо новые языки, и в них, видимо учтены потреьности разработчиков (но производительность плачет просто). А горбатиться над каждой буквой, в Си, как наши предки, что-то неохота.
Про Eiffel — почитаю, раньше не слышал.
Есть еще D, но там вроде автор сделал сборку мусора (фиии), и слишком «тяжелые» классы.
Вы наверно С с С++ путаете. у С как раз проблем нет по части избыточности и двусмысленности.
В Питоне очень много такого, что труднокомпилируемо в эффективный машинный код. Например я могу создать функцию test, затем написать test = 0, и test это уже переменная, а не функция, потом сделать class test — теперь это класс, и теперь test() вызовет уже создание объекта, а не функцию в начале. Для компилируемых языков такое поведение слишком непредсказуемо.
Но тем не менее существует shed-skin.blogspot.com, который пытается именно заниматься компиляцией хотя бы определенной части языка.
Но тем не менее существует shed-skin.blogspot.com, который пытается именно заниматься компиляцией хотя бы определенной части языка.
Это да, но в реальных примерах редко встречаются такие преобразования. Все-таки переменные обычно используются для хренения величин одного типа.
Хорошо, другой пример — например я могу объявить список test = [], а затем добавить в него 3(число), объект какого-нибудь класса, еще что-нибудь, например другой список, затем сделать for i in test: i.print(), что сначала попытается вызвать метод print у числа, затем у объекта, затем у списка. И если я добавлю обработчик исключений — то это правильно сработает, независимо от того у какого числа из этих объектов есть этот метов. Представьте себе какая головная боль это перевести в C++.
Ну в таких языках обычно в переменной хранится и ее тип, так что интерпретатор знает, какой метод вызвать. Никто не запрещает сделать обобщенный метод print(any), который определяет тип переменной и вызвыает нужный код. Так что при компиляции мы все равно чуть-чуть выиграем — на экономии времени на интерпретации байткода.
Но гораздо больший выигрыш будет, когда например компилятор определит что переменная хранит только int, и сразу вызовет метод print(int) для нее, не проверяя тип переменной во время работы программы.
Правда, сомневаюсь, что свободное сообщество способно такой компилятор сделать, даже майкрософт и сан сделали какую-то кривую тяжелую поделку, а не нормальный язык программирования, а от Open Source лучшего ждать глупо.
Но гораздо больший выигрыш будет, когда например компилятор определит что переменная хранит только int, и сразу вызовет метод print(int) для нее, не проверяя тип переменной во время работы программы.
Правда, сомневаюсь, что свободное сообщество способно такой компилятор сделать, даже майкрософт и сан сделали какую-то кривую тяжелую поделку, а не нормальный язык программирования, а от Open Source лучшего ждать глупо.
Все-таки переменные обычно используются для хренения величин одного типа.
В питоне — вовсе не «обычно». Самый наглядный пример — там много где может лежать и обычно лежит либо «привычный» для переменной тип, либо None. Ну, или в одну и ту же переменную может попасть объект типа int или long (совершенно другой по архитектуре). Или str и unicode.
«test» не становится ни функцией, ни классом. Разве что указывает на другой объект.
PyPy does not support the CPython C API, which means that third party libraries for python, written in C, will not work.Это значит, что MySQLdb с ним использовать нельзя?
Видимо. Но не так давно появился проект биндинга к MySQL на чистом питоне: pymysql
Да, не получиться. Но выше советуют, что можно попробовать RPyC (http://morepypy.blogspot.com/2009/11/using-cpython-extension-modules-with.html)
Как-то исследуя различные оптимизаторы кода в рамках контрольной работы по курсу «Архитектура высокопроизводительных ЭВМ» исследовал различные оптимизаторы Python'а и наткнулся на psyco(тут можно почитать подробнее psyco.sourceforge.net/introduction.html извините не могу вставлять html-код) и там же узнал, что для 64-битных платформ он не поддерживается и что мол если вам нужен psyco для x86_64 посмотрите в сторону PyPy.
Мне интерпретатор питона на питоне так же показался рекурсивным извращением, но немного погоняв псайко я подумал, что видимо в рамках реализации этого интерпретатора разработчики пытаются обойти ограничения прямой оптимизации генерируемого байт-кода. Ещё поудмал, что может у них что-то и получится. Видимо так и вышло :)
Для реализации контрольной работы выбрал CorePy. О нём уже писали вот здесь habrahabr.ru/blogs/python/45726/. По личному опыту скажу, что оно действительно работает и на самом деле снова привносит в программирование на ассемблере фан.
Мне интерпретатор питона на питоне так же показался рекурсивным извращением, но немного погоняв псайко я подумал, что видимо в рамках реализации этого интерпретатора разработчики пытаются обойти ограничения прямой оптимизации генерируемого байт-кода. Ещё поудмал, что может у них что-то и получится. Видимо так и вышло :)
Для реализации контрольной работы выбрал CorePy. О нём уже писали вот здесь habrahabr.ru/blogs/python/45726/. По личному опыту скажу, что оно действительно работает и на самом деле снова привносит в программирование на ассемблере фан.
Прямо наплыв питона, что вы в нем нашли? аж завидно стало, что он так постоянно развивается.
А какие «плюшки языка» вы бы советовали использовать?
Все! :)
Классы, очень широкую библиотеку расширений (PyPi, easy_install), исключения (первое время после PHP напрягает что любая ошибочка вызывает остановку, если не предусмотрена обработка, потом PHP начинает напрягать, что он молча пропускает ошибки), генераторы(великая вещь!), стандартную библиотеку, конечно вдоль и поперек надо изучить — полезного очень много. Такие вещи как: if 1 < x < 10, [(i+1) for i in range(10) if i%2==0], a,b=b,a, и т.п.
Еще здесь — stackoverflow.com/questions/101268/hidden-features-of-python
И что важно — очень чистый синтаксис — все программы Python очень аккуратно форматированы (иначе просто не запустятся).
Классы, очень широкую библиотеку расширений (PyPi, easy_install), исключения (первое время после PHP напрягает что любая ошибочка вызывает остановку, если не предусмотрена обработка, потом PHP начинает напрягать, что он молча пропускает ошибки), генераторы(великая вещь!), стандартную библиотеку, конечно вдоль и поперек надо изучить — полезного очень много. Такие вещи как: if 1 < x < 10, [(i+1) for i in range(10) if i%2==0], a,b=b,a, и т.п.
Еще здесь — stackoverflow.com/questions/101268/hidden-features-of-python
И что важно — очень чистый синтаксис — все программы Python очень аккуратно форматированы (иначе просто не запустятся).
Отсутствие public и private, конечно может быть решение с которым я не очень согласен, но привык — таков питон, в нем все можно динамически переназначать.
Кроме того, методы можно называть __method_name — тогда они не будут видны снаружи класса.
Я не гоню на PHP — это очень успешный язык. Я говорю о том, что многие решения в Python куда лучше сделаны чем в PHP. Но конечно пространства имен в PHP — это решение, которое меня будет доооооолго еще озадачивать (за использование "\" на PHP гнать надо).
Кроме того, методы можно называть __method_name — тогда они не будут видны снаружи класса.
Я не гоню на PHP — это очень успешный язык. Я говорю о том, что многие решения в Python куда лучше сделаны чем в PHP. Но конечно пространства имен в PHP — это решение, которое меня будет доооооолго еще озадачивать (за использование "\" на PHP гнать надо).
Новость хорошая, а подача очень слабая. Попробуйте перед восторженными криками почитать что ли внимательно. По пунктам всей ветке:
1. пишется он на RPython, на самостоятельное чтение;
2. транслятор с python на C++ есть — shed-skin.blogspot.com/;
3. есть драйвера к базам данных, написанные на чистом python.
Короче жгете.
1. пишется он на RPython, на самостоятельное чтение;
2. транслятор с python на C++ есть — shed-skin.blogspot.com/;
3. есть драйвера к базам данных, написанные на чистом python.
Короче жгете.
Хорошая новость и не всё равно ли, как они добились ускорения, если пользователям от этого только лучше? Надеюсь, что разговоры о медлительности Питона пойдут на убыл.
Прикольно, конечно, но чтобы писать на джанго помимо ждрайверов к БД почти всегда нужен как минимм PIL, а чтобы писать для десктопа — PyQt. Ни того, ни другого нету… В итоге эксперимент, конечно, интересный, но всего лишь эксперимент.
>please consider it a beta version to try things out.
когда выйдет полноценная версия, тогда и можно подумать об использовании.
когда выйдет полноценная версия, тогда и можно подумать об использовании.
А можно поподробнее, в чем суть JIT-компилятора? Обычный питон ведь тоже компилирует исходники в байт-код.
если ваш тест корректен, но да, увеличение скорости в 9 раз я зафиксировал
Для руби тоже существует подобный проект — Rubinius. Отличия в том что он поддерживает стандартные си расширения Ruby и видимо младше PyPy — текущая версия 1.0.0rc3. А вот perl на perl или php на php я что-то не припомню :)
>Для руби тоже существует подобный проект — Rubinius
разве? Я думал Rubinius — это просто реализация виртуальной машины Руби под LLVM?
разве? Я думал Rubinius — это просто реализация виртуальной машины Руби под LLVM?
Rubinius это прежде всего руби на руби. Некоторые части написаны на C++ а llvm используется для ускорения выполнения кода.
>Rubinius is an implementation of the Ruby programming language.
>The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby.
Тут как я понял тоже самое
>The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby.
Тут как я понял тоже самое
Не очень только понятно зачем было пинать unladen swallow, коли он вообще из другой плоскости.
из другой?..
Unladen swallow — an optimization branch of CPython, intended to be fully compatible and significantly faster.
что интересно они сели на свой JIT — никаких связей с LLVM, JVM, .NET
(как я помню, с LLVM они пробовали, но любовь не сложилась.)
Было бы прикольно, если бы они выделили свой JIT в самостоятельный проект…
(как я помню, с LLVM они пробовали, но любовь не сложилась.)
Было бы прикольно, если бы они выделили свой JIT в самостоятельный проект…
они сейчас активно занимаются всем тем что вы сказали. пишут бэкэнды для LLVM, JVM и для .NET
на самом деле сейчас PyPy уже не так сильно привязан к питону. она зарождался как питон на питоне, чтоб быть более переносимим и легко можно было прототипировать новые фишки. но сейчас на нем можно писать что угодно. это по сути есть фреймворк, где вы на спецязыке RPython (по сути питон без динамичных плюшечек) пишите интерпретатор, аннотируете его местами и фреймворк генерит вам интерпретатор с джитом. в теории можно писать не только для питона. просто наверно никто этим пока не занимался.
на самом деле сейчас PyPy уже не так сильно привязан к питону. она зарождался как питон на питоне, чтоб быть более переносимим и легко можно было прототипировать новые фишки. но сейчас на нем можно писать что угодно. это по сути есть фреймворк, где вы на спецязыке RPython (по сути питон без динамичных плюшечек) пишите интерпретатор, аннотируете его местами и фреймворк генерит вам интерпретатор с джитом. в теории можно писать не только для питона. просто наверно никто этим пока не занимался.
Потестировал PyPy 1.2 на Mac OS X в связке с Джанго. Написал целый пост по результатам: vostryakov.ru/blog/14-testiruem-pypy-12-s-dzhango-12/
Спасибо за наводку!
Спасибо за наводку!
Sign up to leave a comment.
Вышел PyPy 1.2 и ускорил Python в разы!