LINUX.ORG.RU

Pyston 0.5

 ,


0

2

25 мая вышла версия Pyston 0.5. Pyston — это реализация Python (2.7, в будущем — и 3.x) с использованием JIT-технологий LLVM.

Главное изменения этой версии - переход на сборку мусора через подсчет ссылок (ранее использовался tracing GC); это сделано для большей совместимости с существующими модулями расширения CPython (который, как известно, использует подсчет ссылок). В результате Pyston исполняет весь набор тестов NumPy практически без ошибок (1-3 сбойных теста, в зависимости от версии NumPy); правда, производительность при этом в 2 раза ниже, чем у CPython (из-за известных ограничений Pyston).

Среди негативных последствий перехода на подсчет ссылок — снижение общей производительности на 10% по сравнению с Pyston 0.4; следующий релиз (ожидаемый очень скоро) будет сфокусирован на улучшении производительности.

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

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 4)

А зачем оно нужно при производительности ниже оригинала?

Ответ «Потому что LLVM» сам по-себе «не катит».

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

А зачем оно нужно при производительности ниже оригинала?

Производительность ниже CPython - на тестовой сюите NumPy. Версия 0.4 была быстрее CPython на 25% (не бог весть что, но всё же быстрее, и работы по увеличению производительности считай не начинались).

Но да, может получиться еще одна Unladen Swallow.

tailgunner ★★★★★
() автор топика

Чем оно лучше nim?

anonymous
()

(который, как известно, использует подсчет ссылок

из-за известных ограничений Pyston

Как будто курсовую читаешь. Это известно, то очевидно.

arcanis ★★★★
()

Прикладная ценность сего продукта равна нулю. Чисто учебный проект для своих создателей.

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

Прикладная ценность сего продукта равна нулю.

Прикладная ценность будет определена позже.

Чисто учебный проект для своих создателей.

В случае успеха, это стандартный интерпретатор Python для Dropbox.

tailgunner ★★★★★
() автор топика

Pyston — это реализация Python 2.7

шел 2016 год..

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

Трассирующий гц обычно оппозит консервативного, то есть он знает структуру любого объекта и может пройти по ссылкам внутри него. Таким образом можно узнать, какие объекты из всех когда-то созданных доступны сейчас из глобалов/стек-фреймов, и собрать недоступные. Консервативный не знает структуру объектов и может лишь угадывать поинтер-паттерны, считая их ссылками. Например для сишки есть boehm-gc.

Но в питоне трейсинг просто by definition, так что имеется ввиду, что раньше тут не было рефкаунтов в принципе. В обычном питоне они всегда были наряду с гц для циклов, иирц.

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

Толксы и танцпол. Ну и Сишечка, потому-что она душевная и ламповая.

MrClon ★★★★★
()

У меня на днях дошли руки попробовать Nuitka. Вроде как он транслирует код питона в C++, а затем компилирует его. Ну, мою поделку он скомпилировал, я правда не заметил разницы, как потребляла 20МБ и 50% ядра, так и потребляла (моя поделка). Поэтому решил не заморачиваться. Хотя может в каких-то случаях производительность и должна повыситься... По мне так такой вариант компиляции в нативный код куда интересней чем все эти JIT и PyPy...

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

У меня на днях дошли руки попробовать Nuitka

Это инструмент другого назначения - чтобы интерпретатор с собой не тащить. Ускорения он by design не дает (точнее, может, но это сложно и возможности ограничены).

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

Ну так а как без счетчиков ссылок? Каждый раз заново проходить весь граф объектов по ссылкам? Этож как оно шину памяти с процессором нагружает?

AVL2 ★★★★★
()

Фраза «поставить пистон» приобрела новое значение.

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

Циклодетектор этот тот же марксвип, вид сбоку. Без визитов все равно ничего не узнать, или там какая-то новая убертехнология?

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

man incremental gc, generational gc.

Рефкаунты тоже нагружают, не нагружает ее только «ручной привод».

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

Ну так а как без счетчиков ссылок? Каждый раз заново проходить весь граф объектов по ссылкам? Этож как оно шину памяти с процессором нагружает?

Счетчик тоже нагружает. Только счетчик работает постоянно на каждый чих, а в других вариантах сборка мусора производится время от времени. И это вполне может быть эффективней счетчика, но многое зависит от задачи, оптимизаций, устройства и реализации GC, кол-ва памяти, фаз луны и т.д.

anonymous
()

нет чтоб просто переписать критические участки на Go или Rust и успокоится.

нет хитрый гвидо Ван опоссум снова пытается впаририть свой улучшенный питон dropbox как это он делал гуглу

anonymous
()
Ответ на: комментарий от arturpub

Циклодетектор этот тот же марксвип, вид сбоку

Допустим. И что с того? Ты вообще Python C API видел?

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

хитрый гвидо Ван опоссум снова пытается впаририть свой улучшенный питон dropbox

В топике какой-то феститваль наркоманов - у одного Pyston учебный, у другого Pyston пишет Гвидо. Откуда вы такие беретесь.

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

у другого Pyston пишет Гвидо. Откуда вы такие беретесь.

На опеннете вроде как пролетала новость относительно недавно, где говорилось, что за пистоном стоит Гвидо.

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

На опеннете вроде как пролетала новость относительно недавно, где говорилось, что за пистоном стоит Гвидо.

Кем говорилось и на каких основаниях?

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

Конечно видел, все в пиобжектах и рефкаунтинге. По-моему тебе кажется я с чем-то спорю (на самом деле нет).

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

Вроде как он транслирует код питона в C++, а затем компилирует его.

Почему бы тогда не взять C++?

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

Состоялся пятый выпуск проекта Pyston, в рамках которого компанией Dropbox, в которой работает Гвидо ван Россум, развивается высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM.

http://www.opennet.ru/opennews/art.shtml?num=44490

Окай, обманулся — не написано, что Гвидо его пилит.

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

Почему бы тогда не взять C++?

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

RageAgainstMachine
()

Эти ненужнисты лучше бы PyPy пилили, или хотя бы давали им денег, но нет ведь, а там годно.

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

We have number of goals that we think are not possible to meet on the PyPy platform: performance consistency and scalability, and first-class extension module support.

Вот же неосиляторы. Между прочим недавно CPyExt был адски ускорен, а будет ещё лучше. Просто Armin'у некому за это заплатить, а ему самому этим заниматься противно.

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

Да там вообще перл на перле:

Pyston uses a global interpreter lock (or «GIL»), similar to CPython. We experimented with a GIL-free mode, but my (kmod) impression is that this is not solvable given current Python semantics and programs (strong atomicity and memory ordering guarantees).

Мммкей.

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

Эти ненужнисты лучше бы PyPy пилили, или хотя бы давали им денег, но нет ведь, а там годно.

Эти «ненужнисты» - прагматики. Возможно, они выдадут соместимый продукт раньше, чем PyPy. Даже если он будет в 5 раз быстрее CPython, но, если он будет drop-in replacement, он выиграет.

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

А зачем нужно столько разных нену^Wпитонов?

Да ладно, всего 3 штуки. Жабоскр^WДругих ненужно гораздо больше.

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

Знаю. PyPy - скорость, Pyston - совместимость, CPython - референсный. Всё настолько очевидно, что и говорить не о чем.

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

Очевидно только тем, кто вникал. Мне пока не довелось.

Про скорость могу понять - очевидный профит. А в чем прикол делать «ищщоодинпитон» с упором на совместимость? NIH?

Ну например на норма^Wдругих языках бизнесу нужны собственные реализации для независимости и продавливания стандартов. А разве эти питоны тоже в составе каких-то корпораций?

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

Про скорость могу понять - очевидный профит. А в чем прикол делать «ищщоодинпитон» с упором на совместимость?

Этот Python тоже будет быстрее. Может, не в 5-6 раз, как PyPy, а всего раза в 2-3, но за счет полной совместимости его можно будет пустить в продакшен прямо сразу, и в масштабах Dropbox это будет мгновенным профитом.

NIH?

NIH? Это почти «Unladen Swallow наносит ответный удар».

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

А как же jython, ironpython, brython/skulpt, всякие micropython, stackless

Да ровно никак. Их считай что не существует.

не считая cython, nuitka, pyrex, shedskin

Вообще из другой оперы.

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

Может, не в 5-6 раз, как PyPy, а всего раза в 2-3, но за счет полной совместимости

А у PyPy разве не предполагается полная совместимость? Почему?

anonymous
()

правда, производительность при этом в 2 раза ниже, чем у CPython (из-за известных ограничений Pyston).

Не совсем понятно, о каких ограничениях речь...

Главное изменения этой версии - переход на сборку мусора через подсчет ссылок (ранее использовался tracing GC)

А какова мотивация такого перехода?

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

А у PyPy разве не предполагается полная совместимость? Почему?

Я не нстоящий сварщик, объясняю как понимаю: внутренняя архитектура PyPy абсолютно не похожа на CPython и сделать там сборщик мусора на подсчете ссылок невозможно или невыгодно, поэтому там tracing GC. Производительности pure Python code в разы выше CPython, но обращения к расширениям дороги из-за необходимости предоставлять им reference counting поверх tracing GC (и, вохможно, чего-то еще). Полная совместимость предполагается, но за несколько лет так и не достигнута.

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

Не совсем понятно, о каких ограничениях речь...

А какова мотивация такого перехода?

По ссылке написано. Я не стал переводить весь блог-пост.

tailgunner ★★★★★
() автор топика

Кто-нибудь может пояснить, что из перечисленного здесь лучше всего для расчётов? А то мне питон очень хорошо подходит в плане работы с массивами, но есть мысль, что можно и быстрее.

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

Возможно, они выдадут соместимый продукт раньше, чем PyPy. Даже если он будет в 5 раз быстрее CPython, но, если он будет drop-in replacement, он выиграет.

Ключевое слово тут «возможно», только вероятность этого невелика, по-моему. PyPy уже существует, стабильно и является drop-in replacement в очень многих случаях, даже когда требуются бинарные модули --- если они привязаны через cffi, всё отлично (и количество таких пакетов, как ты мог бы видеть растет), а если нет, и боттлнек не в передаче информации, по крайней мере, большинство сейчас работает через CPyExt. И про скорость, тут речь часто идет даже не о каких-то 5x, а куда больше...

Если бы эту имплементацию Крис Латтнер писать намылился, это одно дело, может быть я бы смотрел на неё позитивнее. Его код я видел, и какой он дизайнер он всем уже показал, а другое дело, когда за это взялся малограмотный клоун kmod из КидайКоробки, и его рассуждения и код мы тоже все видим.

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