Оптимизирующий компилятор для Python

это же из прошлогоднего SoC ?
да он еле работал тогда - только как PoC

http://www.linux.org.ru/jump-message.jsp?msgid=1089820

ИМХО бесполезная вещь. По крайней мере на стадии разработки. Фишка таких языков как раз в интерактивном программировании. А тут: напиши, преобразуй, скомпили, запусти... Мрак. Если хочется скорости и отсутствия segmentation fault'ов, use Java. Да к тому же к Java уже какую-то интерактивность применили. Была такая новость на ЛОРе: что-то типа Ruby + Java.

Тогда Jython

> Тогда Jython

скорее Pyjon

// wbr

ребята зачем вам быстрый Пайтон? Пайтон нужен не быстрый, а простой.

А в этом случае лучше Руби. Он даже еще тормознее. Жаль Питон, окончательно попал в руки идеалистов, скоро от его простоты и читабельности ничего не останется.

Абсолютно согласен. Сила Python именно в его простоте. Однако для всяких флеймо-флудеров устраивающих священные войны "Python vs all others" это будет не бесполезной новостью. Теперь у них будет аргумент "за скорость." :)

Кто мешает написать на питоне *просто*, а потом с помощью этой дури заставить работать *быстро*?

А почему в С++ а не в С ??? :) А что Python такой тормоз ?

Был ведь еще .net python (ironpython)... Правда, он попал в лапы m$. Можно питона с моно скрестить?

А что такое Pyjon ?
Google на эту тему молчит

>Если хочется скорости [...] use Java

Хы! Скорость и жаба? Молодой человек, закусывать надо.

С плюсами по скорости жабе тягаться бесполезно.

>По тестам скорость выполнения возрастает до 220 раз в сравнении с CPython, в среднем в 45 раз.
русский язык неисчерпаемо могуч...

>А что такое Pyjon ?

Пижон - он и есть пижон

Скорость Python и так вполне нормальная. Если же ее реально будет не хватать, что обычно случается в больших проектах (которые, в свою очередь, на Python редко пишутся) то гораздо проще и удобнее критичные участки кода реализовать на C(++) и встроить в программу на Python. И ошибок меньше и все преимущества Python сохраняются.

Дело говоришь!

"на Python редко пишутся"

Из-за скудоумия и тупости ;) Основное назначение Питона - быстрая и гибкая связка нативных кусков проекта. С простым, очень компактным (2-10 раз комактнее Жабы) и понятным синтаксисом . А если какому-то мразматику захотелось на чистом коровом Питоне математику считать - дык лечится надо.

Кстати, Питону почти близнец по идеологии Тикль. Только синкасис его не такой изящный как у Питона.

Что же касательно Жабки - юзать одновременно несколько аппликух на жабе нужно быть либо жабодевелопером, либо мазохистом. Время старта и требовательность к памяти - это те параметры, по которым и Питон и Тикль уделывают Жабу по самые помидоры. А быстрота математики в Жабе... Подключи к Питону нативные либы (напр. NAG) и преимущества жабки ужо не так и очевидны.

Собственно говоря, ничего нового. Более продвинутый Pyrex.

> Основное назначение Питона - быстрая и гибкая связка нативных кусков проекта.

У Python много нишь, эта - лишь одна из них.

> ... математику считать - дык лечится надо.

Ну мне приходилось. Ничего, шустренько так работает. :)

> Жабу по самые помидоры

У Python и Java разные ниши. Java хороша в больших проектах где требования к памяти не самое главное. Python в таких проектах используется в качестве прототипа отвечая на вопросы - "попрет или нет?".

> Подключи к Питону нативные либы (напр. NAG)

Ну это и в Java можно сделать. :)

> Скорость Python и так вполне нормальная.

Не надо меня лечить. У меня есть возможность сравнить скорость работы apt и emerge :)

> то гораздо проще и удобнее критичные участки кода реализовать на C(++)

Зачем это делать, если можно сабжем сконвертировать, что и даст желанное увеличение скорости без переписывания (в идеале) и клепания ошибок.

По моему Вы даже новость не удосужились прочитать...

>>Кстати, Питону почти близнец по идеологии Тикль. Только синкасис его не такой изящный как у Питона. вот как раз синтаксис для связки (glue) у тикля лучше -- меньше конструкций. а там где надо моделировать объедками (объектами), то лучше Рубин. вообще говоря мне в последнее время стало ясно, что писанина объедками на С++ удобна лишь своей лучшей повторяемостью кода. но моделировать на С++ не удобно. для оперирования обеъктной моделью лучше Смолтолка не придумали, а к нему ближе все таки Рубин.

>>Зачем это делать, если можно сабжем сконвертировать, что и даст желанное увеличение скорости без переписывания (в идеале) и клепания ошибок. По моему Вы даже новость не удосужились прочитать...

Это вы не удосуживетесь врубаться...

> ИМХО бесполезная вещь. По крайней мере на стадии разработки.

А по-моему, это шаг к статической проверке типов в Python. Я бы убил ради этого 8) Всем хорош Python, но статической типизации не хватает (ИМХО)

Питоновый скрипт можно (с некоторыми ограничениями) сконвертировать в .cpp, откомпилировать и пользоваться. При этом работать будет быстрее. Зачем мне что-то переписывать, если можно обойтись без переписывания? Я не имею в виду, что сабжем можно и нужно полностью заменять питон.

Вопрос: во что я не врубился? Объясните, если в состоянии. Я очень внимательно прочту и подумаю.

Для любителей сводить всё к кошкам и блошкам: я не имею в виду сляпаную на коленке в целяю увеличения пениса CMS для студенческой хоумпаги.

> Если хочется скорости и отсутствия segmentation fault'ов, use Java.

В Java есть segmentation faults - просто они называются NullPointerAssignmemnt :P

(не флейма ради - просто не удержался)

Я с питоном не знаком, но разве он не производит байт код как перл ? И если производит, то это разве не должно повышать скорость работы ?

> Не надо меня лечить. У меня есть возможность сравнить скорость работы apt и emerge :)

Я не доктор чтоб кого-то лечить. И у меня нет возможности для сравнения apt и emerge. Зато у меня есть возможность сравнить проекты на Python с проектами на C/C++/Java 2 в других областях. И практика показывает, что "медленный" Python очень часто является результатом кривых рук товарищей на нем писавших.

> Зачем это делать, если можно сабжем сконвертировать, что и даст желанное увеличение скорости без переписывания (в идеале) и клепания ошибок.

Угу и получить большое (потенциально, конечно) количество ошибок в run-time которые нельзя поправить без перекомпиляции.

> Питоновый скрипт можно (с некоторыми ограничениями) сконвертировать в .cpp

Ограничения приведите.

Врубиться надо в то, что динамику все равно на Си не переведешь. И самое главное и не для чего.

а я бы убил бы за дополнительные костыли и в так уже засранный идеалистами Питон. Как хорошо что вы еще не добрались до Рубина. Не пользуйтесь им - Рубин тормоз! Настоящие программисты пишут на ассемблере!!!

> И практика показывает, что "медленный" Python очень часто является результатом кривых рук товарищей на нем писавших.

Обеими руками солидарен.

> Угу и получить большое (потенциально, конечно) количество ошибок в run-time которые нельзя поправить без перекомпиляции.

Говоря Вашими же словами: "является результатом кривых рук товарищей на нем писавших"

> Ограничения приведите.

<cite>
Компилятор использует неявную статическую типизацию, т.е. синтаксис языка не меняется, и явного объявления типов не требуется. При этом на программу накладывается ряд естественных ограничений, связанных с невозможностью отобразить ряд динамических свойств Python на С++.
</cite>

Динамического приведения типов в качестве примера будет достаточно за глаза.

> Врубиться надо в то, что динамику все равно на Си не переведешь.

Откуда вытекает заключение, что в это я не врубаюсь?

> И самое главное и не для чего.

Я уже сказал, что не рассматриваю сабж, как *тотальную* замену питону.
Но, данный подход имеет право на жизнь и в некоторых случаях может быть полезен.

>>Но, данный подход имеет право на жизнь и в некоторых случаях может быть полезен.

в каких?

> а я бы убил бы за дополнительные костыли и в так уже засранный идеалистами Питон.

Ты бы убил _за_, а я _ради_ ;)

Это лучше спросить у автора про его 16 нетривиальных тестов.

http://mark.dufour.googlepages.com/

For a set of 16 non-trivial test programs, measurements show a typical speedup of 2-40 over Psyco, about 12 on average, and 2-220 over CPython, about 45 on average (see Section 5 of my Master's Thesis on the right).

>>Но, данный подход имеет право на жизнь и в некоторых случаях может быть полезен.

> в каких?

например когда питон используется для создания прототипа приложения, который затем переписывают на C++

первая версия кода получается забесплатно

имхо, ключевой момент здесь -- даже не скорость, а полная независимость полученного кода от питоновского рантайма.

> Говоря Вашими же словами: "является результатом кривых рук товарищей на нем писавших"

Ни коим образом. Это как раз "дань" динамической природе Python. Компилятор не ловит почти ничего, 90% ошибок выявляются во время runtime check.

> Динамического приведения типов в качестве примера будет достаточно за глаза.

А так же: "Second, Python programs cannot currently freely use the Python standard library."

Ради интереса попытался скомпилить этой софтиной довольно простой файл, ну и, конечно: *ERROR*:[путь]: module names should consist of letters, digits and underscores

После всего этого становится ясно, что для написания хоть сколько нибудь сложных программ на Python просто не выполнимая задача. Впрочем это было и так понятно. А программки а-ля "hello world" я и на C++ напишу.

ты бы

integer &_ради_

>>например когда питон используется для создания прототипа приложения, который затем переписывают на C++. первая версия кода получается забесплатно

уточним альфа-версия забесплатно. потом посчитай сколько уйдет на отладку того, что будет нулевым релизом.

>>имхо, ключевой момент здесь -- даже не скорость, а полная независимость полученного кода от питоновского рантайма.

а чем плоха такая зависимость?

>>После всего этого становится ясно, что для написания хоть сколько нибудь сложных программ на Python просто не выполнимая задача. Впрочем это было и так понятно. А программки а-ля "hello world" я и на C++ напишу.

кстати не совсем верно это конечно. пишут и сложное и весьма. и даже настолько, что простота и читаемость Питона становится раком. О том и речь не надо все мешать в кучу Питону питоново.

Кстати посмотрите в Chapter 5 список его тестов: http://kascade.org/shedskin.pdf Не результаты даже, а именно список тестов.

Прошу прощения, я не проверил данную фразу.

Ее стоит читать так:

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

>По тестам скорость выполнения возрастает до 220 раз в сравнении с CPython, в среднем в 45 раз.

"Так кто на ком стоял?".

>Тогда Jython

На чисто вычислительных задачах, ради которых, вроде бы, оптимизация и идёт, Jython - тормоз. На рекурсивном вычислении Фибоначи тормознее чистого Python'а в 22(!) раза. (Осенью сравнивал)

>А что Python такой тормоз ?

Всё относительно. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&...

>С плюсами по скорости жабе тягаться бесполезно.

Речь, вроде бы, шла он Python vs Java.

>>например когда питон используется для создания прототипа приложения, который затем переписывают на C++. первая версия кода получается забесплатно

> уточним альфа-версия забесплатно. потом посчитай сколько уйдет на отладку того, что будет нулевым релизом.

хочешь сказать что если руками переписывать на плюсы, времени уйдёт меньше?

> а чем плоха такая зависимость?

а зачем люди вообще пишут прототипы?

> А так же: "Second, Python programs cannot currently freely use the Python standard library."

ключевое слово -- "currently"

>>хочешь сказать что если руками переписывать на плюсы, времени уйдёт меньше?

нет. этого сказать не хочу. и не хотел. и не сказал.

>>а зачем люди вообще пишут прототипы?

для того чтобы их использовать и оптимизировать. и причем тут вопрос про прототипы? цитируйте полностью "имхо, ключевой момент здесь -- даже не скорость, а полная независимость полученного кода от питоновского рантайма.": поэтому возник вопрос, если скорость не важна, а важна независимость, с точки зрения человека, чем эта зависимость плоха?

посмотрел. тесты они и есть тесты. единственно могу признать, что в очень узком кругу задач вы сможете безболезненно (и то сильно сомневаюсь) перевести какую либо библиотеку для дальнейшего пользования, но про целый проект - это утопия. и потом почему обязательно в Си? ну-ка дайте мне ваши полпроцента прироста работы Си в сравнении с каким нить Эйфелем! :)