Представлен (http://morepypy.blogspot.com/2010/11/pypy-14-ouroboros-in-pr...) релиз проекта PyPy 1.4 (http://pypy.org/), в рамках которого разрабатывается реализации языка Python, написанная на языке Python. Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет (http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20&env=1&hor=false&bas=2%2B35&chart=normal+bars) по производительности классическую реализацию Python на языке Си. Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти.В PyPy также поддерживается бесстековый (Stackless) режим работы, позволяющий добиться массового параллельного выполнения микро-нитей (micro-threads). Для выполнения кода к которому нет доверия реализован режим изолированного выпо...
URL: http://morepypy.blogspot.com/2010/11/pypy-14-ouroboros-in-pr...
Новость: https://www.opennet.ru/opennews/art.shtml?num=28810
График — какая-то дурацкая расческа из единичных столбиков. Если уж изображать относительную производительность, то как-то так: http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20&env=1&hor=true&bas=2%2B35&chart=relative+bars
Не просто расческа, там даже на 1.0 тика и линии нет. Не верю, что люди, которые не могут нормально график нарисовать, могут написать эффективную реализацию питона.
> Не просто расческа, там даже на 1.0 тика и линии нет. Не
> верю, что люди, которые не могут нормально график нарисовать, могут написать
> эффективную реализацию питона.это не график, а именно диаграмма (прочитайте подписи) и не может быть графиком - столбцы не имеют естественного порядка кроме алфавитного по подписям
Нет никакогй разницы как это называется, важно что это сделано абсолютно безграмотно.
Ты адекватен? Картинка абсолютна нормальная.
> Отдельно на базе 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`_."М-да... Можно гланды удалять через задний проход, а можно и компиляторы писать на Питоне :)
А еще можно компиляторы от интерпретаторов не отличать и из тестовых опытов по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
> А еще можно компиляторы от интерпретаторов не отличатьМожно и не отличать. Только в данном случае речь идет именно о (JIT) компиляторе.
> и из тестовых опытов
> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
>> А еще можно компиляторы от интерпретаторов не отличать
> Можно и не отличать. Только в данном случае речь идет именно о
> (JIT) компиляторе.Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова про JIT там нет. Уже сама постановка такой задачи подразумевает возможность почти неограниченной оптимизации, и первичный тестовый код вообще не может рассматриваться как нечто неизменное, тем более результаты тестирования быстродействия.
Хотя сам pypy конечно использует JIT и он полноценный в отличии от урезанного в CPython, также добавлю что первоначальная реализация pypy также в разы проигрывала по скорости CPython, сейчас как видно на графике, большинство тестов на pypy выполняется в разы быстрее и это конечно не предел.
>> и из тестовых опытов
>> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
> А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)А они существуют? Хотя конечно в python можно вставлять инструкции и на С и на Assembler, что позволяет создать компилятор на python, но создание исполняемых бинарников не входит в область применения этого языка и задачи им решаемые.
> Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова
> про JIT там нет.Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."
>>> и из тестовых опытов
>>> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
>> А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
> А они существуют?Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может, то, наверное, какие-то НЕ "сторонние" может? :)
> Хотя конечно в python можно вставлять инструкции и на
> С и на Assembler, что позволяет создать компилятор на python, но
> создание исполняемых бинарников не входит в область применения этого языка и
> задачи им решаемые.Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на
С и на Assembler.Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы. Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие. Так что единственное его достоинство - это то, что на нем можно писать быстро. :)
>Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."Да из микса двух независимых новостей, в одной из которых говориться об реализации JIT для pypy, а в другой о интерпретации стороних языков, можно сделать далеко идующие неверные выводы.
>Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может,
Привет, приплыли, я такого не говорил. Читать читать и еще раз читать вникая в каждое слово.
>Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на
С и на Assembler.
Можно, но не удобно.
>Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы.
Можно, но не удобно.
>Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие.
Ни одной реализации не существует. С чего вы сделали вывод?
Что-то мне подсказывает, что если взять Сишную реализацию питона и оптимизировать ее с установкой "можно жрать больше памяти", то прирост будет не только в "некоторых операциях". Да и лишних тормозов в остальных операциях не возникнет.
Нет.
Учить матчасть, казаться не будет.
Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.
> Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые
> азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.Вы что нибудь про Just-in-time compilation слышали?
Кто ж не слышал. JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых. Чтобы обгоняли - что-то не слышал...
Отлично, теперь вы можете понять почему интерпретатор на python будет обгонять сишную реализацию, не считая конечно реализацию unladen-swallow.
Думаю, тут требуются некоторые подробности. Для начала - данные, где реально показывался бы обгон. "Некоторые операции" рассматривать смысла нет, пока в целом реализация заметно тормознее и прожорливее. Я верю, что есть операции, где язык более высокого уровня позволяет меньше "гонять порожняк", чем универсальная реализация на С. Но это просто оптимизация нескольких узких мест, немного смягчающая общее падение производительности.
>Для начала - данные, где реально показывался бы обгон.Но этож полный здец, график приведен вверху.
На этом графике показан обгон в трех тестах из двадцати и провал в остальных. Как вы думаете, что вас ждет при переходе от тестов к реальным приложениям?
Чукча не читатель...
Да там английским по белому написано рядом с осью:
относительные секунды, чем меньше тем лучше.
Т.е. в соответствии с диаграммой PyPy рвёт во всех местах кроме трёх.
Как в жизни происходит - другой вопрос.
Тут пардон, об...ся ;)
Но для меня лично это больше говорит о проблемах CPython, чем о крутизне PyPy.
И к этому графику стоит внимательно присмотреться именно разработчикам С-реализации. Ведь PyPy - это, по большому счету, очередная итерация их же кода.
>Ведь PyPy - это, по большому счету, очередная итерация их же кода.Ага, плюс, сюрприз, полный jit
> На этом графике показан обгон в трех тестах из двадцати и провал
> в остальных. Как вы думаете, что вас ждет при переходе от
> тестов к реальным приложениям?Я таки думаю нужно вам кофейку попить, чтобы правильно понимать графическую информацию и прочитать таки про JIT, хотя бы тут http://en.wikipedia.org/wiki/Just-in-time_compilation
После этого вопрос должен быть закрыт.
Кофейку - обязательно.
А вот вопрос я бы не закрывал, пока не увидел такой же график, но с эталонным CPython свежей версии, скомпилированным с оптимизацией под эту платформу.
И мой исходный тезис - что CPython можно ускорить, заменив основные алгоритмы на более прожорливые по памяти, никто даже не попытался аргументированно опровергнуть...
>пока не увидел такой же график, но с эталонным CPython свежей версии, скомпилированным с оптимизацией под эту платформу.Извиняйте, и еще раз график вверху, синеньким это CPython. Прошу прощения, но дальшейшие объяснения бесмыслены, вы не хотите даже прочитать хоть малую толику материалов и путаете оптимизацию конкретной бинарной программы коей является CPython и оптимизацию всего кода для интерпретации в JIT.
Ваши "объяснения" ограничиваются одной аббревиатурой, продолжать действительно бессмысленно. А на графике - CPython позапрошлой версии, который при компиляции ориентировался на работу на любом i686 (если не i486) и минимум оперативки. А запущен он на Xeon с 12 гигами памяти. Если бы тестеров интересовала скорость, а не показатели...
> CPython можно ускорить, заменив основные алгоритмы на более прожорливые по памятиМожет быть можно. Может быть нельзя. Пальцем ткните - какие основные алгоритмы вы хотите заменять. Иначе разговор какой-то беспредметный получается. Вы ведь не ждёте, что кто-либо начнёт доказывать что CPython принципиально нельзя ускорить? Вот есть такой проект - psyco (http://psyco.sourceforge.net/) - JIT для CPython. В принципе - ускоряет. А в конкретном случае может быть неприменим.
Я, пожалуй, закончу спор, согласившись с оппонентами.
Сравнение CPython с PyPy - это на самом деле не противопоставление, а проверка работы самого PyPy. Эта работа нужна и обоснована - как бы ни старались разработчики CPython ускорить интерпретатор, проблема неэффективного кода на Python, выполняющегося в этом интерпретаторе, никуда не денется. Именно в этом цель и смысл PyPy - оптимизация пользовательского кода, а не ускорение интерпретатора.
Таким образом, PyPy - это не "более быстрый Python", это "выпрямитель" программ, написанных на Python, "скармливающий" результаты CPython'овским процедурам. Так сказать, оптимизирующий интерпретатор.
Теперь до меня это дошло. Спасибо за интересную полемику ;)
>как бы ни старались разработчики CPython ускорить интерпретатор, проблема неэффективного кода на Python, выполняющегося в этом интерпретаторе, никуда не денетсяАга, цельный гугл над этим работает и ничего сделать не может.
>Таким образом, PyPy - это не "более быстрый Python", это "выпрямитель" программ, написанных на Python, "скармливающий" результаты CPython'овским процедурам. Так сказать, оптимизирующий интерпретатор.
Блин... Сил уже нет. PyPy не использует CPython, совсем не использует, это отдельная реализация, а не надстройка над CPython. Ознакомтесь уже с мат. частью http://ru.wikipedia.org/wiki/PyPy
Ладно, не использует. Использует свой, с аттракционами, способ выполнения Python-кода.
Не факт, что в случае компиляции в С получающийся машинный код так уж сильно отличается от процедур CPython. Но это неважно.
Важно то, что он не только выполняет код (как CPython), но вначале его перерабатывает и оптимизирует. Поэтому, собственно, действительно может работать быстрее.
> JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых ...хотите сказать что преобразование инструкций в машинный код (во время обработки интерпретируемой программы) -- это костыли?
...ну тогда с таким же успехом можно сказать что и "Архитектура фон Неймана" вычислительных машин -- это тоже костыли (в отличии от "Гарвардской архитектуры" вычислительных машин)
:-)
JIT, в принципе, делает то же самое, что и С-компилятор, только не один раз при создании программы, а каждый раз при ее работе. Появился JIT именно из-за того, что чистая интерпретация тормозит невыносимо. И это не костыль? Еще скажите, что замыкания - это не глюк сборщика мусора, возведенный в принцип ;)
>JIT, в принципе, делает то же самое, что и С-компилятор, только не один раз при создании программы, а каждый раз при ее работе.А вот и нет. Каждый раз не требуется, если конечно код не меняется, а вот время компиляции инструкций в байт-код значительно меньше.
>И это не костыль?
Костыль подразумевает под собой "лишний программный код" и всякое отсутвие плюсов, по сравнению с реализацией без костыля, а плюсы JIT таковы:
- кроссплатформенность,
- значительная скорость разработки,
- легкость изменения кода без накладных расходов.Что это дает:
- возможность использования в энтерпрайз-системах, как бы пафосно это не звучало, но при гетерогенности примененных решений и платформ, например сборной солянки из операционных систем и серверов и корпоративных информационных систем (КИС), что как правило используется на больших предприятиях, вы можете это все довольно легко связать, без особых проблем, и с наименьшими затратами, и все это может обслуживаться одним легко доступным на рынке типом специалиста --- как итог значительный профит.
Это не плюсы JIT, это плюсы интерпретируемого языка. С обычной платой за это - пониженной скоростью, которая подпирается костылем JIT. Да, это очень верное и полностью обоснованное решение, но с какого перепугу ему обгонять по скорости нативный, откомпилированный с оптимизацией под конкретную платформу код - решительно непонятно.
> Это не плюсы JIT, это плюсы интерпретируемого языка. С обычной платой за
> это - пониженной скоростью, которая подпирается костылем JIT. Да, это очень
> верное и полностью обоснованное решение, но с какого перепугу ему обгонять
> по скорости нативный, откомпилированный с оптимизацией под конкретную платформу код -
> решительно непонятно.А теперь представь КИС (корпоративную информационную систему), чье внедрение занимает не один месяц или даже не один год. Представил? Скорость работы имеет какое-либо значение по сравнению со скоростью разработки/внедрения? Для сравнения стоимость серверного оборудования занимает не более процента от стоимости внедрения КИС.
> но с какого перепугу ему обгонять
> по скорости нативный, откомпилированный с оптимизацией под конкретную платформу код -
> решительно непонятно.Потому что python это инерпретируемый язык, и оптимизацией его байт-кода под конкретную платформу занимается как раз таки JIT.
Где вы вообще в данной теме матчасть нашли?
судя по "расческе", как ее тут окрестили, против природы все же не попрешь. Памяти стабильно жрет в два раза больше, а общая желтая полоска явно короче общей синей. Накладные расходы дают о себе знать.
Но сама новость в позитивных тонах :)
Жаль не поддерживается psycopg2
а на чем написан питон, на котором написана эта реализация питона?
На питоне!BA-DA-TUM-TSSS...
ну и что, Delphi писали на Delphi, C++ на С++
Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" из лишнего кода вокруг того, что действительно надо сделать в конкретном случае.
Оптимизирующий компилятор может бороться с этой регрессией, но в случае интерпретируемых языков его нет...
Python же умеет компилировать в ".pyc" файлы. Может быть когда-нибудь...
Это не компиляция, а просто удаление лишнего, комментариев и т.п.
Однако, преобразование исходного текста программы в байткод стековой виртуальной машины - это вполне компиляция.
В моем посте ключевое слово - не "компилятор", а "оптимизирующий"
> Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" ...жесть! ну и анекдот :DDDDDDDD
...а на чём же ещё можно написать программу (в том числе интерпретатор-или-компилятор) -- КРОМЕ как на языке программирования?
...неужто на Волшебной Мане? :-D
когда пишешь <чтото> на Волшебной Мане -- то "обёртки" -- не растут? :-)
А вы не в курсе, что любой язык программирования высокого уровня - это обертка над машинным кодом, позволяющая оперировать более сложными сущностями и не взорвать мозг?
Причем чем выше уровень языка, тем больше в этих обертках "мусора", помогающего создать более или менее универсальную абстракцию ценой выполнения лишних команд и использования лишней памяти.
Компилирую последний nasm (libvpx попросил). Смотрю на процесс - а он на Си. Жду nasmnasm.