Pymothoa — новый JIT-компилятор для Python

Limitations:

• Does not support exception.
• Does not support Python objects.
• Only work on module-level function; not class methods

сыроватая поделочка.

Это не JIT-компилятор для Python.

«Programming in the Pymothoa dialect is similar to writing in C. Variables must be declared and are statically typed. Despite a few extra constructs, the syntax is the same as raw Python code».

Это не PyPy и не Unladen, а что-то вроде Cython.

Это не PyPy и не Unladen, а что-то вроде Cython.

Так в репах же есть стандартный гсс, и он же может пистон в бины валять и так.

А в чем мотивация проекта, если есть PyPy,Cython?

Так в репах же есть стандартный гсс, и он же может пистон в бины валять и так.

Ссылку можно?

https://pay.reddit.com/r/Python/comments/vuud2/pymothoa_a_jit_extension_to_py...

я просто не знаю как там обстоят дела с Cython в плане кода.

С разморозкой ;)

yum info gcc-python-plugin-docs

Да неважно. Pymothoa фактически вводит еще один язык, очень похожий на Python, но всё-таки не Python. Программы придется модифицировать

С разморозкой ;)

Ты просто мало знаешь о том, о чем пытаешься говорить.

yum info gcc-python-plugin-docs

Я просил ссылку, а не странную RedHat-специфичную хрень.

Если речь об этом: https://fedorahosted.org/gcc-python-plugin/, то никакого отношения к теме это не имеет. И к «валять пистон в бины» это тоже отношения не имеет.

Так нафиг оно надо? Код будет быстрее работать или нет?

Так нафиг оно надо?

Для оптимизации «узких мест» в Python-программах без написания Си-расширений.

Код будет быстрее работать или нет?

Пока ты его не пометишь специальным образом - нет, после пометки - да.

Ты просто мало знаешь о том, о чем пытаешься говорить.

Я вообще то спросил.

Я просил ссылку, а не странную RedHat-специфичную хрень.

Если что то гсс и много чего это тоже шапка пилит, и давай не будем углубляться в эту сторону...

И к «валять пистон в бины» это тоже отношения не имеет.

И что по твоему мнению делает ЭТОТ плугин ?

ЭТОТ плугин ?

 yaourt -Ss gcc python
aur/gcc-python-plugin 0.9-3 (2)
    Allows the invoking of arbitrary Python scripts from inside the compiler

Allows the invoking of arbitrary

А ну тогда понятно :)

Токо вроде не произвольного а токо си ...

И что по твоему мнению делает ЭТОТ плугин ?

Это инструмент для написания анализаторов кода на Python. Специально для тебя продублирую ссылки:

«links against libpython, and (I hope) allows you to invoke arbitrary Python scripts from inside the compiler».

Чтобы два раза не вставать: фраза «links against libpython» означает, что используется стандартный интерпретатор Python. О том, что используется JIT или AOT, нет ни слова.

http://translate.google.com/#en|ru|Allows%20the%20invoking%20of%20arbitrary%20Python%20scripts%20from%20inside%20the%20compiler

Ты забыл указать что оно ещё требует явного указания типов для всех переменных.

В общем, я так и не понял для чего это нужно.

1) Оно даже менее удобное чем cython и требует явного указания типов

2) требует переписывания сырцов, причём синтаксис таки зверский (я думаю это для того чтобы заткнуть синтаксический парсер который нерасширяем, увы).

Я рад движухе вокрук питона (глядишь когда-нить будет быстро работать), но, имхо, не стоит плодить лишние диалекты.

Кстати, господа, как думаете - стоит ли к питону развивать расширяемость парсера? Или мы получим перл? А то местами бы эта функция явно не помешала бы.

1) Оно даже менее удобное чем cython и требует явного указания типов

На первый взгляд, оно гораздо удобнее cython.

стоит ли к питону развивать расширяемость парсера?

Для протокола: Pymothoa этого не требует.

оно гораздо удобнее cython.

чем? Что не надо запускать внешних комманд и всё внутри питона делается? А cython у меня немодифицированные исходники хавал. Я, кстати, думаю, что cython тоже можно в декоратор обернуть.

Pymothoa этого не требует.

что порождает костыли типа var(blah=your_type).

Чем оно лучшпе psycho?

оно гораздо удобнее cython.

чем?

То, что не нужен *.pyx и нет *.so.

cython у меня немодифицированные исходники хавал

Cython - это по существу транслятор Python -> C + Python API, он схавает немодифицированные исходники и сделает из них такой же код, как и CPython.

И у меня есть подозрение, что пока Cython не станет Ъ-компилятором, со всем «умностями» настоящих компиляторов, он в принципе проигрывает LLVM.

что порождает костыли типа var(blah=your_type).

cdef и cython.{declare,struct} в Cython тебе костылями не кажутся?

Кстати, господа, как думаете - стоит ли к питону развивать расширяемость парсера? Или мы получим перл? А то местами бы эта функция явно не помешала бы.

Не нужно. Альтернативные костыльные синтаксисы для всего чтобы через них выражать DSL - тоже.

Альтернативные костыльные синтаксисы для всего чтобы через них выражать DSL - тоже.

да вообще дайош один ЯП для всех!

И у меня есть подозрение, что пока Cython не станет Ъ-компилятором, со всем «умностями» настоящих компиляторов, он в принципе проигрывает LLVM.

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

Никаких «умностей» в Cython не надо. Он и так полностью функционален. Ни в одном языке или его реализации не видел более удобного способа создания нативных модулей.

Ну либо один перл6, либо не нужно в питоне, да.

пока Cython не станет Ъ-компилятором, со всем «умностями» настоящих компиляторов, он в принципе проигрывает LLVM.

Смотря во что они будут играть, в футбол или теннис.

В подкидного дурака.

Ни в одном языке или его реализации не видел более удобного способа создания нативных модулей.

Pymothoa - это средство обойтись вообще без нативных модулей при сохранении приемлимого быстродействия. Если ты не понимаешь этого, бросай программирование и играй в футбол или теннис. А лучше - играй в дурака, там тебе даже играть не придется.

тем, что хотя бы как-то разивается и не зависит от платформы. Psycho i386 only.

это средство обойтись вообще без нативных модулей

КО говорит это средство удобного создания нативных модулей. Притом, с учётом того что даже динамическая типизация похерена, от питона там остались лишь ошмётки синтаксиса.

это средство обойтись вообще без нативных модулей

КО говорит это средство удобного создания нативных модулей.

Пока КО не подтвердит свои слова ссылкой на Вики проект, я буду считать, что он просто не понимает, что такое JIT.

Притом, с учётом того что даже динамическая типизация похерена, от питона там остались лишь ошмётки синтаксиса.

К Cython это относится еще в большей степени.

Притом, с учётом того что даже динамическая типизация похерена, от питона там остались лишь ошмётки синтаксиса.

а динамическая типизация разве вообще возможна при компиляции?

он просто не понимает, что такое JIT.

да один хрен что JIT что статическая компиляция нужны для скорости. Достигается это одним и тем же способом - путём получения исполняемого процом кода.

Обычно JIT применяется с динамическими языками. Путём трасировки кода они пытаются понять его поведение и собрать статически (во всяком случае я себе так представляю). В этом же случае даже трасировать ничего не нужно т.к. все функции сугубо статические. Плюс тут только поддержка простейших типов типа int и float. По сути чуваки обернули C в питонячий синтакс. Так где тут динамика-то? Код на выходе всегда один и тот же.

а динамическая типизация разве вообще возможна при компиляции?

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

да один хрен что JIT что статическая компиляция нужны для скорости. Достигается это одним и тем же способом - путём получения исполняемого процом кода.

Только вот JIT генерирует код каждый при исполнении программы, так что адаптация к внутренним ABI интерпретатора происходит автоматически.

Обычно JIT применяется с динамическими языками.

«Обычно»? Самый распространенный JIT - для Явы.

По сути чуваки обернули C в питонячий синтакс. Так где тут динамика-то? Код на выходе всегда один и тот же.

Кто вообще говорит о динамике? Если тебе не трудно, прочитай Pymothoa — новый JIT-компилятор для Python (комментарий) и скажи, с чем именно ты споришь.

адаптация к внутренним ABI интерпретатора происходит автоматически.

Убедил, у нас уже есть cpython и pypy которые сильно разнятся.

Самый распространенный JIT - для Явы.

нахрен он тогда там? :)

скажи, с чем именно ты споришь.

это же лор, спорим обо всём на свете.

у нас уже есть cpython и pypy которые сильно разнятся.

Еще они разняться для разных версий CPython, а с Pymothoa мы (теоретически) получаем автоматическую совместимость везде.

Самый распространенный JIT - для Явы.

нахрен он тогда там? :)

Тоже для перевода набора команд VM в набор команд ЦП, но для статически типизированного языка.

они разняться для разных версий CPython

там api давно стабилизировался, я не видел изменений кроме как при py2 => py3 миграции.

Слишком много ограничений => не нужно, есть Pypy.

Тоже для перевода набора команд VM в набор команд ЦП, но для статически типизированного языка.

что вроде этого?

#!/usr/bin/tcc -run
int main(void) {
  printf("I'm JIT-enabled!");
  return 0;
}

да хватит уже спорить!

просто скажите, что круче — Pymothoa или Cython ? :)

просто скажите, что круче — Pymothoa или Cython ? :)

Круче С !!!

Нет. На вход JIT поступает код JVM, а не исходник на Яве.

Больше похоже на это:

$ uname -m
x86_64
$ qemu-ppc -L $(pwd) bin/ls
...
$

отсутствие поддержки классов,

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

Не понял, чем оно лучше Cython и при чем тут JIT. А еще название нечитабельное.

это таки джит цитон

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

Возможен вывод типов. ShedSkin накладывает на исходники python лишь одно существенное ограничение - ни в одной точке программы переменная не может иметь неоднозначный тип, т.е. функцию типа

def ambiguous(shouldReturnString):
    if shouldReturnString:
        return ""
    else
        return 0

Для оптимизации «узких мест» в Python-программах без написания Си-расширений.

Для превращения своего кода в невалидное для остальных УГ и создания патчей, которые ни один нормальный человек в апстрим не примет.

Для превращения своего кода в невалидное для остальных УГ

Подучи-ка матчасть.

Tested with LLVM 3.1 (may also work for other version).

Сразу видно, уважаемый компишлятор.