Состоялся (https://blog.pyston.org/2016/05/25/pyston-0-5-released/) пятый выпуск проекта Pyston (http://www.pyston.org), в рамках которого компанией Dropbox, в которой работает Гвидо ван Россум, развивается высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM. Реализация примечательна применением современных технологий JIT-компиляции и нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++. Код Pyston написан на языке C++ и распространяется (https://github.com/dropbox/pyston) под лицензией Apache.
В отличие от проекта PyPy (https://www.opennet.me/opennews/art.shtml?num=43218), также продвигающего идею применения JIT для ускорения выполнения Python-скриптов, в Pyston используется не трассирующий JIT, базирующийся на компиляции в машинный код часто выполняемых циклов, а применяемый в современных JavaScript-движках JIT на основе трансляции отдельных методов (method-at-a-time), который, по мнению инженеров Dropbox, является более перспективной технологией. Принцип работы Pyston сводится к разбору кода на языке Python и его трансляции в промежуточное представление LLVM (IR, Intermediate Representation). Далее IR-представление проходит обработку в оптимизаторе LLVM и передаётся для исполнения в JIT-движок LLVM, который преобразует IR-представление в машинный код.Для получения информации о типах переменных для программ на динамическом языке Python применяется техника вероятностного предсказания типов объектов с последующим уточнением правильности выбора типа в процессе выполнения. Таким образом Pyston постоянно варьирует выполнение между двумя ветками - быстрой, когда данные о предсказанных типах подтверждаются, и медленной, используемой в случае рассогласования данных о типе. Работа может осуществляться в многопоточном режиме, допускающем параллельное выполнение нескольких нитей кода на языке Python и избавленном от глобальной блокировки интерпретатора (GIL, global interpreter lock).
В новой версии сборщик мусора переведён на использование метода подсчёта ссылок (https://ru.wikipedia.org/wiki/%D0%9F%D0%... (refcounting) для автоматического управления высвобождением неиспользуемых объектов. Новый метод пришёл на смену отслеживающему сборщику мусора (https://ru.wikipedia.org/wiki/%D0%A1%D0%.... Refcounting более прост в реализации и позволяет заметно увеличить оперативность высвобождения объектов, но он медленнее и не поддерживает обработку зацикленных ссылок. Причиной смены сборщика мусора является использование refcounting в основной реализации CPython - идея перехода на более эффективный отслеживающий сборщик мусора не оправдала себя из-за возникших проблем с совместимостью с C API. Refcounting же ценой некоторого снижения производительности позволяет существенно расширить поддержку уже написанного кода, в котором используются специфичные для refcounting свойства (предсказуемое немедленное уничтожение объектов).
Другим важным улучшением новой версии является достижение уровня совместимости с CPython, позволяющего выполнить немодифицированный вариант библиотеки NumPy. Кроме того, в Pyston 0.5 обеспечены такие изменения, как поддержка обработки сигналов, интроспекция кадров стека при выходе, проведение чистка генератора, расширение поддерживаемых функций C API, поддержка использования немодифицированных библиотек py.test, lxml и cffi. Что касается производительности, то ценой повышения совместимость стало замедление работы примерно на 10%. При подготовке следующей версии основное внимание будет уделено оптимизации производительности.
URL: https://blog.pyston.org/2016/05/25/pyston-0-5-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=44490
> Refcounting ... не поддерживает обработку зацикленных ссылок.И что теперь делать? Есть в пистоне слабые ссылки?
Вариант "думать при написании кода" вы принципиально не рассматриваете?
> думать при написании кодаЭй-эй-эй, полегче! Так ведь можно и на нормальные языки типа C человека перевести. Оно вам надо? Пусть и дальше с питоном в песочнице играется.
Снобизм чаще всего присущ ограниченным людям. Он позволяет им чувствовать себя выше только на основе того, что они выбрали что-то "правильное", например С, а главное позволяет свою неспособность выучить другое замаскировать под нежелание.
> Снобизм чаще всего присущ ограниченным людям. Он позволяет им чувствовать себя выше только на основе того, что они выбрали что-то "правильное", например "думать при написании кода", а главное позволяет свою неспособность выучить другое замаскировать под нежелание.obvious fix
Ого, говорящая энциклопедия!
> Эй-эй-эй, полегче! Так ведь можно и на нормальные языки типа CНазвать костыль с кучей подпорок и полями граблей, типа Си, "нормальным языком" — это сильно.
> Оно вам надо? Пусть и дальше с питоном в песочнице
> играется.Ну возьмите да перепишите свой бубунтософт/портаж и т.д. на Си.
А то в каждой новости о питоне только и можете себя (типа илитных сишников) нахваливать, да плакаться какой не труЪшный этот самый питон и как нужно все сделать "правильно".
А воз и ныне там. Т.е. питонщики хоть как-то работающий софт написали, а от илиты кроме "да мы, да всем, да покажем, вот!!" пока ничего не видно )
> костыль с кучей подпорок и полями граблейМожно примеры костыльности C? Никак не отрицаю вашу (пока только вероятную) правоту, но правда интересно. Вроде как самый элегантный и некостыльный язык из наиболее популярных.
> А то в каждой новости о питоне
Никогда в новостях о питоне не видел, чтоб сишники себя нахваливали. Зато часто вижу, как пользователи в них жалуются на кривизну и нерабочесть софта на питоне. Я правильно понимаю, что это и есть ваше "хоть как-то работающий" и вы считаете, что это хорошо?
> от илиты кроме "да мы, да всем, да покажем, вот!!" пока ничего не видно
Давайте вы напишете это из системы, где софта на python хотя бы просто не меньше, чем софта на C/C++, а я тем временем обдумаю свои встречные аргументы?
> элегантный
#include <asm/kasan.h>
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern pmd_t early_dynamic_pgts[EARLY_DYNAMIC_PAGE_TABLES][PTRS_PER_PMD];
static unsigned int __initdata next_early_pgt = 2;
pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
Типун Вам на язык
>> элегантный
>
> #include <asm/kasan.h>
> extern pgd_t early_level4_pgt[PTRS_PER_PGD];
> extern pmd_t early_dynamic_pgts[EARLY_DYNAMIC_PAGE_TABLES][PTRS_PER_PMD];
> static unsigned int __initdata next_early_pgt = 2;
> pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
>
> Типун Вам на языкШо, пионэр, не распарсил?
Да, есть такое. :) Откровенно говоря, я в Сях дальше численных методов не вылазил, поэтому со своей колокольни я могу назвать Си мощным языком, но отнюдь не элегантным.
> отнюдь не элегантнымА как бы выглядел тот фрагмент, чтобы вы сочли его элегантным?
В вашем примере по сути три типа строк:
#include <включаемый_файл>
тип переменная[длина_массива];
тип переменная = значение;Я слабо представляю, как приведённый фрагмент кода можно сделать лучше.
Может быть, вас смущают всякие pmd, pgd, pgt, PTRS, NX? Так в C принято создавать словарь предметной области и сокращать наиболее длинные термины, типа ptr вместо pointer или RO вместо READONLY, и со временем понимаешь, что это удобно.
> Вроде как самый элегантный и некостыльный язык из
> наиболее популярных.А слаще морковки ничего нет?
> Я правильно понимаю, что это и есть ваше
> "хоть как-то работающий" и вы считаете, что это хорошо?Почему-то народ пользуется софтом, который вполне себе справляется с задачей, а не очередным мифическим "Будет самый-самый! Вы все обзавидуетесь! Осталось только написать!"
Но зачем учить недо-язык? Есть гораздо более интересные и перспективные платформы.
> Есть гораздо более интересные и перспективные платформы.Назовите хотя бы три?
>> Есть гораздо более интересные и перспективные платформы.
> Назовите хотя бы три?Эээ... COBOL, LISP и Smalltalk?
>> Есть гораздо более интересные и перспективные платформы.
> Назовите хотя бы три?Не-бейсик, не-гвидобейсик, не-жавоскрипт, не-жаво. 4 достаточно?
Java, Scala + Akka, Groovy.
>Вариант "думать при написании кода" вы принципиально не рассматриваете?пробовал, не помогает. точнее помогает на коде уровня "hello world", дальше эффективность данной методики снижается, при чём чем больше кода, тем ниже эффективность
так весь этот механизм с автоматическим управлением временем жизни объектов (все эти гэрбэйдж-коллекторы разных типов и систем, подсчет ссылок в их числе) и делается обычно для того, чтобы ты при написании кода думал о бизнес-логике, а не об особенностях управления памятью. А тут вроде есть механизм автоматического освобождения памяти, но помнить о таких досадных утечках (из-за циклических ссылок) ты обязан и должен обруливать сам.
Если Вы соберёте pyston, то сами ответите на вопросы; а если нам свой отзыв напишете - будет совсем хорошо. Мне вот собирать pyston лень.А если почитать blog.pyston.org, то можно найти, что weakrefs есть, а сборку мусора в pyston 0.5 сделали как в CPython.
1) есть
2) Сферический refcounting в воздухе сам по себе не поддерживает, но питон-то поддерживает. Там специальный код для очистки cyclic counters (тормозной, правда, но тем не менее). И в пистоне он также работает.
https://docs.python.org/3/library/weakref.html
Крутые анонимусы всегад синят на python скорее всего куча реализованных проектов за плечачи и давит на них их низкая производительность и ущербность. У нас в компании реалзован один из крупнейших проектов в Беларуси по контролю кассового оборудования, считайте страну маленкой или большой - но все должно работать практически в realtime, сохранение данных от сотен тысяч устройств, аналитика, и другие прикладные задачи. Стек такой python + ceph + postgres. Или есть какие то основания у анонимуса что мы ошиблись в выборе технологий?
> куча реализованных проектов за плечачи и давитНеграмотной школоте на "плечачи" давят рукава шорт.
А по существу сказать нечего. :)// другой Аноним
>> Стек такой python + ceph + postgresЭто ни о чем не говорит. На любом распространенном языке/платформе можно написать нормально и написать криво. Можно сделать нормальную архитектуру, можно "лапшу" из заплаток. Можно покрыть тестами, можно не тестировать.
Какой язык лучше знают ключевые сотрудники команды - тот и лучше.
Если во главе угла таки бизнес - то команду всегда можно набрать, отталкиваться от конкретных людей, а не от рынка при выборе технологии - глупость.
Незаменимых нет. Можно кодеров набирать студентов, и толкать ынтырпрайз.