https://www.opennet.me/openforum/vsluhforumID3/72885.html Представлен (http://morepypy.blogspot.com/2010/11/pypy-14-ouroboros-in-practice.html) релиз проекта 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-компиляции является более высокое потребление памяти.<br><br><br><br>В PyPy также поддерживается бесстековый (Stackless) режим работы, позволяющий добиться массового параллельного выполнения микро-нитей (micro-threads). Для выполнения кода к которому нет доверия реализован режим изолированного выпо...<br><br>URL: http://morepyp https://www.opennet.me/openforum/vsluhforumID3/72885.html#60 Tue, 30 Nov 2010 20:55:02 GMT Ладно, не использует. Использует свой, с аттракционами, способ выполнения Python-кода.<br>Не факт, что в случае компиляции в С получающийся машинный код так уж сильно отличается от процедур CPython. Но это неважно.<br>Важно то, что он не только выполняет код (как CPython), но вначале его перерабатывает и оптимизирует. Поэтому, собственно, действительно может работать быстрее.<br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#59 Tue, 30 Nov 2010 18:44:48 GMT &gt;как бы ни старались разработчики CPython ускорить интерпретатор, проблема неэффективного кода на Python, выполняющегося в этом интерпретаторе, никуда не денется<br><br>Ага, цельный гугл над этим работает и ничего сделать не может.<br><br>&gt;Таким образом, PyPy - это не "более быстрый Python", это "выпрямитель" программ, написанных на Python, "скармливающий" результаты CPython'овским процедурам. Так сказать, оптимизирующий интерпретатор. <br><br>Блин... Сил уже нет. PyPy не использует CPython, совсем не использует, это отдельная реализация, а не надстройка над CPython. Ознакомтесь уже с мат. частью http://ru.wikipedia.org/wiki/PyPy <br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#58 Tue, 30 Nov 2010 16:53:04 GMT Я, пожалуй, закончу спор, согласившись с оппонентами.<br>Сравнение CPython с PyPy - это на самом деле не противопоставление, а проверка работы самого PyPy. Эта работа нужна и обоснована - как бы ни старались разработчики CPython ускорить интерпретатор, проблема неэффективного кода на Python, выполняющегося в этом интерпретаторе, никуда не денется. Именно в этом цель и смысл PyPy - оптимизация пользовательского кода, а не ускорение интерпретатора.<br>Таким образом, PyPy - это не "более быстрый Python", это "выпрямитель" программ, написанных на Python, "скармливающий" результаты CPython'овским процедурам. Так сказать, оптимизирующий интерпретатор. <br>Теперь до меня это дошло. Спасибо за интересную полемику ;)<br><br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#57 Tue, 30 Nov 2010 16:19:30 GMT Ваши "объяснения" ограничиваются одной аббревиатурой, продолжать действительно бессмысленно. А на графике - CPython позапрошлой версии, который при компиляции ориентировался на работу на любом i686 (если не i486) и минимум оперативки. А запущен он на Xeon с 12 гигами памяти. Если бы тестеров интересовала скорость, а не показатели...<br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#56 Tue, 30 Nov 2010 16:08:58 GMT &gt; CPython можно ускорить, заменив основные алгоритмы на более прожорливые по памяти<br><br>Может быть можно. Может быть нельзя. Пальцем ткните - какие основные алгоритмы вы хотите заменять. Иначе разговор какой-то беспредметный получается. Вы ведь не ждёте, что кто-либо начнёт доказывать что CPython принципиально нельзя ускорить? Вот есть такой проект - psyco (http://psyco.sourceforge.net/) - JIT для CPython. В принципе - ускоряет. А в конкретном случае может быть неприменим.<br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#55 Tue, 30 Nov 2010 14:09:45 GMT &gt;Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."<br><br>Да из микса двух независимых новостей, в одной из которых говориться об реализации JIT для pypy, а в другой о интерпретации стороних языков, можно сделать далеко идующие неверные выводы. <br><br>&gt;Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может,<br><br>Привет, приплыли, я такого не говорил. Читать читать и еще раз читать вникая в каждое слово.<br><br>&gt;Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на<br><br>С и на Assembler.<br><br>Можно, но не удобно.<br><br>&gt;Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы.<br><br>Можно, но не удобно.<br><br>&gt;Но на практике мы видим, что компиляторы на Питоне получаютс https://www.opennet.me/openforum/vsluhforumID3/72885.html#54 Tue, 30 Nov 2010 13:44:04 GMT &gt;пока не увидел такой же график, но с эталонным CPython свежей версии, скомпилированным с оптимизацией под эту платформу.<br><br>Извиняйте, и еще раз график вверху, синеньким это CPython. Прошу прощения, но дальшейшие объяснения бесмыслены, вы не хотите даже прочитать хоть малую толику материалов и путаете оптимизацию конкретной бинарной программы коей является CPython и оптимизацию всего кода для интерпретации в JIT. <br> https://www.opennet.me/openforum/vsluhforumID3/72885.html#53 Tue, 30 Nov 2010 12:44:17 GMT &gt; Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова<br>&gt; про JIT там нет.<br><br>Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."<br><br>&gt;&gt;&gt; и из тестовых опытов<br>&gt;&gt;&gt; по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.<br>&gt;&gt; А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)<br>&gt; А они существуют?<br><br>Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может, то, наверное, какие-то НЕ "сторонние" может? :)<br><br>&gt; Хотя конечно в python можно вставлять инструкции и на<br>&gt; С и на Assembler, что позволяет создать компилятор на python, но<br>&gt; создание исполняемых бинарников не входит в область применения этого языка и<br>&gt; задачи им решаемые.<br><br>Чтобы создать ко https://www.opennet.me/openforum/vsluhforumID3/72885.html#52 Tue, 30 Nov 2010 12:19:40 GMT Кофейку - обязательно.<br>А вот вопрос я бы не закрывал, пока не увидел такой же график, но с эталонным CPython свежей версии, скомпилированным с оптимизацией под эту платформу. <br>И мой исходный тезис - что CPython можно ускорить, заменив основные алгоритмы на более прожорливые по памяти, никто даже не попытался аргументированно опровергнуть...<br>