Представлен (http://shed-skin.blogspot.com/2011/06/shed-skin-08-programmi...) релиз проекта Shed Skin 0.8 (http://code.google.com/p/shedskin/), в рамках которого развивается экспериментальный компилятор Python-скриптов в представление на языке C++. Поддерживается генерация как обособленных исполняемых программ, так и модулей, которые после компиляции можно импортировать в Python-проекты с целью оптимизации производительности. В новой версии Shed Skin добавлена (http://code.google.com/p/shedskin/wiki/releasenotes?ts=13084...) поддержка новых модулей (array, struct), решены проблемы с работой на 64-разрядных системах, добавлены новые оптимизации и исправлены ошибки. Код Shed Skin распространяется в рамках лицензии GPLv3.Для компилируемых скриптов обязательным требованием (http://shedskin.googlecode.com/files/shedskin-documentation-...) является использование статической типизации (в процессе работы скрипта тип переменной не должен изменять...
URL: http://shed-skin.blogspot.com/2011/06/shed-skin-08-programmi...
Новость: http://www.opennet.me/opennews/art.shtml?num=31099
> Для компилируемых скриптов обязательным требованием является использование статической типизациипотому что компилятор дурачок и не умеет по другому. проанализировать код, вывести типы и наделать где надо параметризованых функций он не может. велосипед с квадратными колёсами.
Таких компиляторов просто нет, нельзя анализировать динамический код и заменять его типизированными вставками. По крайней мере для ЯП типа питона.
> Таких компиляторов просто нет, нельзя анализировать динамический код и заменять его типизированными
> вставками. По крайней мере для ЯП типа питона.автор Stalin'а очень удивлён: он, оказывается, сделал то, что сделать нельзя.
питон значительно отличается от хаскеля, нет в яп достаточной интроспецкии в сишные потраха. Даже ципкл в питоне формально нельзя развернуть в статический код.
бред щас сказал. К тому же Stalin - схема. Хотя какая разница, да.
ну конечно. Разверни вот такой код детерминированно в статикfrom math import fabs
print reduce(lambda x,y: x + fabs(y), xrange(10))
и подумай зачем, например, в некоторых PL/SQL есть атрибуты у храминок типа IMMUTABLE,
STABLE, VOLATILE. Зачем похожие вещи есть в inline ассемблерах, в сях/поюсах const и т.п.> К тому же Stalin - схема. Хотя какая разница, да.
в общем то да, в данном случае разница не велика. всё одинаково далеко от питона
> ну конечно. Разверни вот такой код детерминированно в статики что? очевидно, что это работа с числами.
> всё одинаково далеко от питона
гвидобейсик такой гвидобейсик.
> и что? очевидно, что это работа с числами.Тебе с твоим человечьим мозгом может быть, и то не очевидно, ты просто догадываешься глядя на знакомые литералы чисел. А с формально логической точки зрения (т.е. как на этот код смотрит потенциальный компилятор или анализатор питонокода) здесь вообще чисел нет и этот код ни во что больше не разворачивается. А именно в цикле участвует мутабельный объект (итератор) и волатильная функция (fabs - вызов сишной ф-ии).
даже такому альтернативно развитому, как ты должно быть ясно, что библиотечные функции аннотированы. что такое xrange — компилятор знает. что такое reduce — компилятор знает. итого — это спокойно компилятором разворачивается в простой цикл с инлайнингом fabs. задачка для школьника десятого класса. мой JIT умеет разворачивать намного более закрученые штуки, к тому же в динамике. а тут вообще халява — весь код изначально компилятору скормили.
ах, да: конечно, JIT не для гвидобейсика: недоязыки меня не интересуют.
компилятор не знает что такое fabs(), _не_ знает что такое reduce(). Да и в контексте питона под xrange может быть что угодно. Прежде чем нести такую чушь ознакомтесь с немного с мат. частью. Я кончно понимаю что у вас всё на одно лицо, но тем не менее везде есть существенные различия.
> компилятор не знает что такое fabs(), _не_ знает что такое reduce().это очень, очень глупый компилятор значит. детсадовский. впрочем, гвидобейсик же — какой контингент, такие и программы.
Анализировать динамический код и выводить по возможности типы переменных умеет любая современная IDE, посмотри что ли на продукты JetBrains.
не в обиду, но - не умеет. Вернее умеет, но только то, что задана в её внутренностях. Реально, где она рулит - джава. Надо понимать за счет рефлексии и реверса - это для неё нативно.
это всё "эвристический" вероятностный анализ. Для формального детерминированного выполнения он совсем не подходит, а для разбора в первом приближении вполне.
> потому что компилятор дурачокВообще, господин Тюринг выдвинул довольно интересную теорию: одна программа никогда не сможет полностью проанализировать работу другой программы. Поэтому кой-кто прямо так и хочет попрыгать по этим граблям и попытаться сделать то, чего достичь невозможно даже теоретически :)
> Вообще, господин Тюринг выдвинул довольно интересную теорию: одна программа никогда не
> сможет полностью проанализировать работу другой программы.и поэтому анализаторы вообще не нужны, ага.
Странно, что в тесте Sudoku компилятор оказался в 31 раза быстрее CPython и в 4 раза быстрее PyPy.
Если прочитать это предложение в обратную сторону, то получится, что на PyPy этот тест выполняется в разы быстрее, чем на CPython.Это не очень логично — CPython изначально должен быть быстрее всех остальных интерпретаторов, кроме Jython (поскольку там JIT).
Или я чего-то не понимаю? Может в PyPy оптимизации какие хитрые есть?
Кто-нибудь из знатоков Питона может объяснить?
Я ошибся — в 25 раз быстрее, чем в CPython.
В PyPy есть JIT. Собственно, для этого он и делался, чтобы быть быстрее CPython.
Не для этого он делался.
Это площадка для экспериментов, на Python (PyPy) писать проще чем на C (CPython). И JIT здесь можно считать очередным экспериментом, который появился достаточно быстро (ну в CPython его ещё нет и будет ли) именно благодаря выбранному языку реализации...bw
>Не для этого он делался.Для этого.
>Это площадка для экспериментов, на Python (PyPy) писать проще чем на C (CPython).
Он не на Python а на RPython написан.
CPython самый медленный так как интерпретатор, а PyPy - быстрый так как использует JIT-компиляцию."Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си - при выполнении 20 тестов производительности PyPy в среднем опережает CPython в 3.6 раз."
http://www.opennet.me/opennews/art.shtml?num=30422
вот здесь: http://snowplow.org/martin/rebench/ хороший Regular expression speed comparison для perl, python, rubyУ меня python 2.6.5 проигрывает по скорости perl 5.10.1 от 2х до 8 раз (в одном тесте в 20) (Ubuntu 10.04).
IronPython 2.6 проигрывает обычному python в ~10 раз.
PyPy 1.2.0 проигрывает обычному python от 2 до 20 раз.Интересно как в этой штуке.
> У меня python 2.6.5 проигрывает по скорости perl 5.10.1 от 2х до
> 4х раз (в одном тесте в 20) (Ubuntu 10.04). IronPython 2.6
> проигрывает обычному python в ~10 раз.в синтетических тестах? слабый показатель. мой доморощеный скриптовый язык, например, в синтетических тестах перл обгоняет. а на самом деле -- тормозит.
Это тесты на регекспы. Там хорошо обыграны разные комбинации.
> Это тесты на регекспы.что вообще имеет мало отношения к скорости языка. вон, на многих часто используемых (и умно составленых) регэкспах tre раскатывает катком и перл, и pcre. если я заменю pcre на tre — я ведь не ускорю язык этим.
у меня некоторый функционал большую часть времени занимается split'ами и регекспами, так что если ускорятся регекспы, то скорость программы ускорится ощутимо.попробовал http://cpansearch.perl.org/src/DGL/re-engine-RE2-0.08/README
RE2 от в 2 раза медленнее, до в 4 раза быстрее
> Это тесты на регекспы. Там хорошо обыграны разные комбинации.У Яндекса какая-то библиотека есть которая делает перл как стоячий обгоняя его в 35 раз на регекспах. К языку синтетические тесты не имеют отношения.
https://github.com/dprokoptsev/pire
Да, спасибо оно.
> У Яндекса какая-то библиотека есть которая делает перл как стоячий обгоняя его
> в 35 раз на регекспах. К языку синтетические тесты не имеют
> отношения.«Pire does not have any Perlish conditional regexps, lookaheads & backtrackings, greedy/nongreedy matches; neither has it any capturing facilities.»
кастраты не интересны.
>«Pire does not have any Perlish conditional regexps, lookaheads & backtrackings, greedy/nongreedy matches; neither has it any capturing facilities.»А прочитать README.RU не судьба
>кастраты не интересны.
Анонимы не интересны.
> У Яндекса какая-то библиотека есть которая делает перл как стоячий обгоняя его в 35 раз на регекспах. К языку синтетические тесты не имеют отношения.Эта библиотека почти ничего из функционала регекспов не умеет, только самое простое. Не умеет даже greedy/nongreedy matches, так что не важно во сколько раз, когда неюзабельно.
> в синтетических тестах? слабый показатель.Нихрена себе синтетика - регэкспы. Они и в реальных программах там и тут :)
> Нихрена себе синтетика - регэкспы. Они и в реальных программах там и
> тут :)ты не в курсе, что тесты регэкспов тоже бывают синтетические?
алсо, в большинстве случаев как раз полномасштабный движок регэкспов не нужен, часто достаточно того subset, например, что в Lua вмонтирован (взял просто первый попавшийся под руку пример).
1.2 это ооочень старая версия - практически без всяких оптимизаций. В 1.3 или 1.4 они как-раз подкрутили регулярки, если мне память не изменяет.
perl там тоже древний, в 5.14 сильно их ускорили
А почему для perl никто компиляторы не пишет? Неуловимый Джо?
> А почему для perl никто компиляторы не пишет? Неуловимый Джо?пишут, parrot. кучу лет уже пишут. ну, это ж перлисты — они ещё долго писать будут.
А транслятор в C или С++ не существует?
> А транслятор в C или С++ не существует?а зачем? O_O
Дык для PHP вон HipHop сделали, а для Perl ничего?
> Дык для PHP вон HipHop сделали, а для Perl ничего?livejournal работает и без хипхопа.
> А транслятор в C или С++ не существует?Кстати да. Зачем?
Критичные участки кожа можно переписать на C\C++ и подключить через XS.
Вспоминается история Rambler почты, когда выкинули perl и переписали всё на Си.
Было 80 серверов, стало 5. Это я к чему, имеет ли смысл писать проекты с высокой нагрузкой на перл или сразу начинать с Си?
parrot - он для всего, в первую очередь для perl6, а потом уже питон, перл5, руби и т.п.