Pyston 0.5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ранее использовался tracing GC

интересно, как это?

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

шел 2016 год..

Питон не нужен

А что нужно?

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

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

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

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

Но в питоне трейсинг просто by definition

O_O

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

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

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

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

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

man incremental gc, generational gc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет, это он в mypy коммитит.

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

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

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

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

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

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

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

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

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'у некому за это заплатить, а ему самому этим заниматься противно.

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

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).

Мммкей.

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

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

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

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

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

То есть не знаешь?

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

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

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

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

А как же jython, ironpython, brython/skulpt, всякие micropython, stackless. Это не считая cython, nuitka, pyrex, shedskin и т.п.

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

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

NIH?

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

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

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

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

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

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

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

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

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

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

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

c extension modules?

http://doc.pypy.org/en/latest/cpython_differences.html

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

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

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

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

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

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

Для быстрой работы с массивами обычно используют NumPy.

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

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

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