LINUX.ORG.RU

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

 , , pymothoa,


0

2

Pymothoa расширяет возможности Python с помощью JIT без модификации кода интерпретатора. Pymothoa работает на уровне приложения, он использует AST, генерируемые Python. Это позволяет пользователю писать оригинальный код на Python, но с небольшими поправками на изменения, вносимые Pymothoa.

Для того чтобы Python произвел JIT-компиляцию, нужно всего лишь декорировать нужную функцию. Pymothoa использует LLVM как бекенд. В сравнении с написанием Си модулей для Python, Pymothoa менее громоздкий и более удобный для распространения исходников, т.к. не требует перекомпилирования модулей.

Написание приложений с использованием диалекта Pymothoa сравнимо с программированием на C. Переменные должны быть декларированы и статически типизированы. За исключением нескольких конструкций, код Python не претерпевает изменений.

На данный момент проект имеет ограничения, такие как: отсутствие исключений, отсутствие поддержки классов, отсутствие поддержки Python-объектов.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Silent (всего исправлений: 3)

Limitations:

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

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

ymn ★★★★★
()

Это не 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.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

mx__ ★★★★★
()

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

pylin ★★★★★
()
Ответ на: комментарий от xpahos

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

tailgunner ★★★★★
()
Ответ на: комментарий от mx__

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

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

yum info gcc-python-plugin-docs

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Siado

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

mx__ ★★★★★
()
Ответ на: комментарий от Bad_ptr

Allows the invoking of arbitrary

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

mx__ ★★★★★
()
Ответ на: комментарий от mx__

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

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

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

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

tailgunner ★★★★★
()

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

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

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

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

чем?

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

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

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

zz ★★★★
()
Ответ на: комментарий от zz

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

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

true_admin ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

tp_for_my_bunghole
()
Ответ на: комментарий от true_admin

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

zz ★★★★
()
Ответ на: комментарий от tp_for_my_bunghole

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Quasar

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

xpahos ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

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

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

xpahos ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от xpahos

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

true_admin ★★★★★
()

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

Deleted
()
Ответ на: комментарий от tailgunner

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

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

#!/usr/bin/tcc -run
int main(void) {
  printf("I'm JIT-enabled!");
  return 0;
}
true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

JFreeM ★★★☆
()

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

pevzi ★★★★★
()
Ответ на: комментарий от true_admin

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

zz ★★★★
()
Ответ на: комментарий от xpahos

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

def ambiguous(shouldReturnString):
    if shouldReturnString:
        return ""
    else
        return 0
Sheskin просто проигнорирует и пойдёт парсить дальше, кинув предупреждение.

quiet_readonly ★★★★
()
Ответ на: комментарий от tailgunner

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

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

quiet_readonly ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.