LINUX.ORG.RU

Проект Unladen Swallow

 , , ,


0

0

Проект Unladen Swallow ("Ласточка налегке", отсылка к Monty Python) имеет целью увеличить производительность интерпретатора Python 2.6.1 минимум в 5 раз. при этом сохраняя совместимость со всеми Python-приложениями и модулями расширения. Проект не рассматривается как форк Python, и все усовершенствования планируется слить в основную ветку.

Самое существенное намеченное изменение - использование LLVM вместо текущей Python-специфичной VM, но запланированы и менее радикальные изменения, направленные на быстрое получение практически полезного ускоренного Python - усовершенствования "классического" интерпретатора (ceval.c), GC, внутренних структур данных, и эксперименты с новейшими GCC. Работа будет разбита на несколько этапов, с ежеквартальными релизами. Более подробный план работы здесь: http://code.google.com/p/unladen-swal..., уже достигнутые результаты здесь: http://code.google.com/p/unladen-swal....

Ссылка на Monty Python: http://www.armory.com/swallowscenes.html

Да, и регулярные выражения тоже планируется починить ;)

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

Хорошо ) Я как раз питон начинаю учить, кстати, можнт кто посоветует что в кач-ве обучающего материала?

GreyDoom ★★★★
()

Вообще интересно, что решение использовать llvm было принято только сейчас, а не во время разработки 2.6.1.

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

>Вообще интересно, что решение использовать llvm было принято только сейчас, а не во время разработки 2.6.1.

А в 3.0 версии не он случаем используется?

wyldrodney
()

> Проект Unladen Swallow ("Ласточка налегке", отсылка к Monty Python)...

А какая ласточка? Европейская или африканская?

lollo
()

Один из возможных рисков - потеря поддержки Windows. :)

void_ptr ★★★★
()

Лучше расскажите, когда питон3 появится в сквизе.

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

> Я как раз питон начинаю учить, кстати, можнт кто посоветует что в кач-ве обучающего материала?

Питоновская документация, интернет и, разумеется, чужие проги в сочетании со своими мозгами :)

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

> день питона на l.o.r?

реквистирую новостей про Perl6 побольше :-)

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

>> Вообще интересно, что решение использовать llvm было принято только сейчас, а не во время разработки 2.6.1.

> А в 3.0 версии не он случаем используется?

Нет. Честно говоря, я вообще не понимаю, какие выгоды даст LLVM - это же хрень для статических языков. А если пройти по ссылке, можно увидеть, что сами разрабы этого тоже еще не понимают. В общем, начиная со второй стадии, проект идет непонятно куда непонятно зачем.

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

>больше похоже на название порнофильма))

С Бин Ладеном в главной роли. :)

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

> Хорошо ) Я как раз питон начинаю учить, кстати, можнт кто посоветует что в кач-ве обучающего материала?

Интерактивный интерпретатор же :-)

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

> Нет. Честно говоря, я вообще не понимаю, какие выгоды даст LLVM - это же хрень для статических языков. А если пройти по ссылке, можно увидеть, что сами разрабы этого тоже еще не понимают. В общем, начиная со второй стадии, проект идет непонятно куда непонятно зачем.

пионеры :D

Joe_Bishop
()

Это к Святому Грааля отсылка? Про кокосы.

Obey-Kun ★★★★★
()

Вот лучше скажите, почему бы этим питонистам юным не приложить свои усилия к реализации питона на parrot. А потом уже совместными усилиями улучшать производительность parrot и конкретно питона под ней?

Очевидно, что коллективными усилиями работа пойдёт лучше.

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

> Я как раз питон начинаю учить, кстати, можнт кто посоветует что в кач-ве обучающего материала?

Смотрите на лучших торрентах "Learning Пистон" by Mark Lutz, Third Edition.

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

> Вот лучше скажите, почему бы этим питонистам юным не приложить свои усилия к реализации питона на parrot.

Потому что слишком много работы до появления реального результата.

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

> Вот лучше скажите, почему бы этим питонистам юным не приложить свои усилия к реализации питона на parrot. А потом уже совместными усилиями улучшать производительность parrot и конкретно питона под ней?

Тоже мучает этот вопрос. Амбиции им чтоли мешают :)

balodja ★★★
()

Питон эт хорошо. А если уж и быстродействие будет такое, так вообще цены ему не будет.

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

> Нет. Честно говоря, я вообще не понимаю, какие выгоды даст LLVM - это же хрень для статических языков. А если пройти по ссылке, можно увидеть, что сами разрабы этого тоже еще не понимают. В общем, начиная со второй стадии, проект идет непонятно куда непонятно зачем.

По ходу LLVM даст более оптимизированный бфйткод что ускорит работу интерпретатора.

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

> А в 3.0 версии не он случаем используется?

Не знаю, у меня душа больше к Ruby расположена :)

Непонятно вот что: почему про существование уже готовых виртуальных машин разработчики различных языков программирования (речь идёт про Ruby и Python) вспомнили только сейчас, когда создали кучу своих VM?

Тут выше говорят, что llvm предназначена для статических языков. Если мне не изменяет память или восприятие окружающей действительности, то что Python, что Ruby - динамические языки. Какой тогда смысл городить километровые костыли для теоретического прироста производительности?

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

> почему про существование уже готовых виртуальных машин разработчики различных языков программирования (речь идёт про Ruby и Python) вспомнили только сейчас, когда создали кучу своих VM?

Бугага. Это вопрос к рубироидам - почему они не использовали Python VM? :D Для справки - Python вышел в 1992 году, Ruby - в 1995.

> llvm предназначена для статических языков. Если мне не изменяет память или восприятие окружающей действительности, то что Python, что Ruby - динамические языки. Какой тогда смысл городить километровые костыли для теоретического прироста производительности?

А вот это хороший вопрос.

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

>А какая ласточка? Европейская или африканская?

Европейская. Африканские не мигрируют.

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

> А вот это хороший вопрос.

Подучите хоть чуть-чуть матчасть, прежде чем рассуждать. Единственный способ улучшить производительность языка - это отказываться от интерпретации в пользу компиляции. Первый шаг - это избавиться от лексического, синтаксического и (иногда) семантического анализа путем компиляции в байт-код. Второй шаг - произвести частичную типизацию, констант-фолдинг, референс-алиасинг, dataflow graph (как минимум). Третий шаг - рантайм-компиляция в нативный код, путем полной типизации при выполнении.

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

> Бугага. Это вопрос к рубироидам - почему они не использовали Python VM? :D Для справки - Python вышел в 1992 году, Ruby - в 1995.

В пистоне на момент выхода Ruby уже была VM? Не заморачивался насчёт истории, наверняка нет. Вообще тенденция такая, воротить на любой случай свою виртуальную машину... Совместимости никакой, одни велосипеды, а ведь есть Parrot.

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

> В пистоне на момент выхода Ruby уже была VM?

В Питоне на момент выхода Рябы - была. А вот в Рябе был интерпретатор AST.

> Не заморачивался насчёт истории, наверняка нет

А ты заморочься. http://python-history.blogspot.com/

> Вообще тенденция такая, воротить на любой случай свою виртуальную машину... Совместимости никакой, одни велосипеды, а ведь есть Parrot.

Ладно, не заморачивайся историей... нам веселее будет.

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

>Хорошо ) Я как раз питон начинаю учить, кстати, можнт кто посоветует что в кач-ве обучающего материала?

читай ЛОР. здесь всё скажут.

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

> Подучите хоть чуть-чуть матчасть, прежде чем рассуждать.

Покажи мне мои рассуждения, гений.

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

Утипути. Ты знаешь, что в Питоне это уже есть?

> Второй шаг - произвести частичную типизацию, констант-фолдинг, референс-алиасинг, dataflow graph (как минимум).

Дадада, я тоже люблю читать статьи по современным интерпретаторам и VM, и знаю много умных слов. Только вот "частичная типизация" на этапе трансляции для Питона еще ни у кого не получалась, Всё остальное - копейки для динамического языка.

> Третий шаг - рантайм-компиляция в нативный код, путем полной типизации при выполнении.

Пруфлинк на то, что LLVM это умеет, или GTFO.

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

> а я думал, что ты не тролль :(

"Ooops... you found out. Now we have to kill you." (c)

А если посмотреть на твои постинги, то про тупых разработчиков, не использующих готовые VM, начал троллить ты.

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

> Утипути. Ты знаешь, что в Питоне это уже есть?

телепат-моде - *.pyc / *.pyo файлы, да? Типа в курсе.

> Дадада, я тоже люблю читать статьи по современным интерпретаторам и VM, и знаю много умных слов. Только вот "частичная типизация" на этапе трансляции для Питона еще ни у кого не получалась, Всё остальное - копейки для динамического языка.

И ты тоже пишешь и оптимизишь компилятор на работе? "Частичная типизация" - спешно читать про понятия "классы типов" и "жадное инстанцирование", а потом уже рассуждать, есть она в Питоне или нет.

Ты, кстати, в курсе, что хеш-контейнеры могут содержать нетипизированные данные? Не, в смысле ВООБЩЕ не типизированные. И гетерогенные. Домашнее задание - понять, при каких условиях такой хеш-контейнер реализуем.

> Пруфлинк на то, что LLVM это умеет, или GTFO. На оффсайте LLVM есть ссылочка documentation, там есть описание llc. Читаем lcc до дыр. А потом ищем туториалы. И узнаем, что вся функциональность llc доступна в качестве библиотечных вызовов в рантайме. 1) Создал Module 2) Набил функциями и переменными 3) Прошел pass'ами оптимизации 4) Запустил кодогенерация 5) Получил в inner-process памяти свежескомпилированный модуль (набор функций. Анализ конкретно Питоновского кода, расставление типизации на него - это уже сугубо Питоновская задача и проблема. А так - открою тебе, малыш, секрет, что даже в интерпретаторах ты всё равно обрабатываешь типизированные данные.

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

>> Утипути. Ты знаешь, что в Питоне это уже есть?

>телепат-моде - *.pyc / *.pyo файлы, да? Типа в курсе.

Ну так нафига "избавиться от лексического, синтаксического и (иногда) семантического анализа путем компиляции в байт-код" - эрудицию показать?

>> Дадада, я тоже люблю читать статьи по современным интерпретаторам и VM, и знаю много умных слов. Только вот "частичная типизация" на этапе трансляции для Питона еще ни у кого не получалась, Всё остальное - копейки для динамического языка.

> И ты тоже пишешь и оптимизишь компилятор на работе?

Нет. А ты "оптимизишь" компилятор Питона?

> "Частичная типизация" - спешно читать про понятия "классы типов" и "жадное инстанцирование", а потом уже рассуждать, есть она в Питоне или нет.

Вражайся яснее. Например, "описанные в <блабла> классы типов есть в Питоне в виде <фу>". А то вопросы задавать - дело нехитрое.

> Ты, кстати, в курсе, что хеш-контейнеры могут содержать нетипизированные данные?

Что такое "хеш-контейнер" в терминах Питона - dict? Тогда знаю. Любой это знает.

> Не, в смысле ВООБЩЕ не типизированные.

О чем ты вообще? Как в Питоне создать "ВООБЩЕ не типизированные данные"?

> И гетерогенные.

Какая банальщина.

>> Пруфлинк на то, что LLVM это умеет, или GTFO.

> На оффсайте LLVM есть ссылочка documentation, там есть описание llc. Читаем lcc до дыр.

Ну хоть один ответ. Значит, llc (или всё же lcc?). OK, почитаем.

> Анализ конкретно Питоновского кода, расставление типизации на него - это уже сугубо Питоновская задача и проблема

Ааааа ты стебешься!!!!1111 :D Именно в этом вся сложность задачи.

> А так - открою тебе, малыш, секрет,

Бгг. Ну не сердись так, откуда мне знать, что нас посещают специалисты по оптимизу компиляторов.

> даже в интерпретаторах ты всё равно обрабатываешь типизированные данные.

Спасибо, К.О.

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

Отвечу на всё скопом.

Если человек считает, что использование llvm в динамически типизируемых языках возможно лишь через костыли - то этот человек либо тролль, либо лжец, либо невежда. Какой вариант тебе ближе?

Если раскрывать тему дальше - llvm даёт тебе низкоуровневый, абстрагированный от аппаратной архитектуры язык (читать проLLVM IR) и набор инструментов к нему:

1) Транслятор из других языков (Си как пример) в LLVM IR

2) Представление в байт-коде, компилятор в нативный код (asm/машинный код) и интерпретатор байт кода.

3) Некоторое множество оптимизаций над ним

4) Набор библиотек для работы с виртуальной машиной/транслятором/компилятором llvm напрямую в рантайме.

Такой инструмент позволяет эффективно (максимально эффективно) реализовать любой компилятор/транслятор.

Но он не решит проблемы за тебя.

Я на работе занимаюсь разработкой и оптимизацией движка СУБД. llvm отлично ложится под выражения и хранимые процедуры. А с вопросами типизации и динамическая типизация vs статическая типизация сталкиваться приходиться на каждом шагу каждый день. Как и с другими "умными словами", про которые ты читаешь статьи.

Самая сложная часть задачи - это проводить семантический анализ кода Питона, и инстанцировать код (точнее, некоторое множество различных вариантов) в зависимости от типов входных данных, шедулить ветви выполнения в зависимости от типа. Мы не можем убрать динамическую типизацию вообще, но мы можем её минимизировать. Если в какой-то точке программы мы встречаем метод .str() что возвращает строку - то все дальнейшие использования этой переменной мы можем пометить типом string. И так далее. Получение информации о типе, или множестве возможных типов (читать: типизация по Карри, можешь поглядеть Харрисоновские лекции по ML http://code.google.com/p/funprog-ru/ ) в любой точке программы позволяет автоматически сузить вероятные варианты программ, соответсвенно как только их число становится меньше некоторой величины то возможным становится произвести компиляцию программы как статической, с некоторыми switch'ами по типам на входных данных.

Не менее сложная часть задачи - эффективная кодогенерация, оптимизация кода под конкретные платформы.

Для интерпретаторов она обязана быть

1) быстрой

2) оптимальной

llvm эту задачу решает целиком и полностью. И где ты увидел костыли?

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

Продолжая тема

Правильно - llc - llvm system compiler

В задачке с хеш-контейнером (который в python'е называется dict) я предлагал тебе подумать над вопрос - при каких условиях ты можешь складывать доставать данные в хеш-контейнером не интересуясь их типом данных?

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

Зачем оно нужно? Эффективная, быстрая реализация хеш-контейнера.

Когда она применима? При условии, что одинаковые значения двух переменных одинакового типа бинарно неотличимы - это раз, два - когда при поиске значения в хеше тебе достаточно найти лишь значения данного типа, и не нужно искать эквивалентные значения другого типа (при поиске строки "5" тебе не нужно находить ещё и числа 5).

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

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

> Если человек считает, что использование llvm в динамически типизируемых языках возможно лишь через костыли - то этот человек либо тролль, либо лжец, либо невежда. Какой вариант тебе ближе?

Тролль, естественно. Только вот где ты увидел, что я говорю о костылях? Я сказал, что не вижу выигрыша в скорости от использования именно LLVM. И я его и до сих пор не вижу.

> Если раскрывать тему дальше - llvm даёт тебе низкоуровневый, абстрагированный от аппаратной архитектуры язык (читать проLLVM IR) и набор инструментов к нему:

> ...

> Такой инструмент позволяет эффективно (максимально эффективно) реализовать любой компилятор/транслятор.

> Но он не решит проблемы за тебя.

Еще раз спасибо, К.О. Только вопрос был не о том, чем является LLVM, а о том, в чем выигрыш от использования именно LLVM, а не Parrot или еще чего-нибудь, специально предназначенного для динамических языков.

> Я на работе занимаюсь разработкой и оптимизацией движка СУБД. llvm отлично ложится под выражения и хранимые процедуры. А с вопросами типизации и динамическая типизация vs статическая типизация сталкиваться приходиться на каждом шагу каждый день. Как и с другими "умными словами", про которые ты читаешь статьи. У тебя длиннее, не вопрос. Непонятно, правда, является ли движок СУБД компилятором и какое отношение он имеет к задаче "ускорить Python в 5+ раз"

> Самая сложная часть задачи - это проводить семантический анализ кода Питона, и инстанцировать код (точнее, некоторое множество различных вариантов) в зависимости от типов входных данных, шедулить ветви выполнения в зависимости от типа.

Причем эта кодогенерация, учитывающая конкретную комбинацию входных типов, выполняется в рантайме. И я повторю вопрос - как LLVM помогает решать _эту_ задачу?

> Получение информации о типе, или множестве возможных типов (читать: типизация по Карри, можешь поглядеть Харрисоновские лекции по ML http://code.google.com/p/funprog-ru/ ) в любой точке программы позволяет автоматически сузить вероятные варианты программ, соответсвенно как только их число становится меньше некоторой величины то возможным становится произвести компиляцию программы как статической, с некоторыми switch'ами по типам на входных данных.

Для полного Питона эту задачу _приемлимо_ решить пока не удалось. А Unladen Swallow явным образом отказывается от проведения своих исследований и собирается опираться на существующие.

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

> Причем эта кодогенерация, учитывающая конкретную комбинацию входных типов, выполняется в рантайме. И я повторю вопрос - как LLVM помогает решать _эту_ задачу?

Прочитай документацию по llvm, а? Ну пожалуйста! Ликуешь сишную либу llvm'а, делаешь последовательные её вызовы, получаешь на выходе сишный указатель на свежескомпилированную функцию.

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

> Причем эта кодогенерация, учитывающая конкретную комбинацию входных типов, выполняется в рантайме. И я повторю вопрос - как LLVM помогает решать _эту_ задачу?

Если же твой вопрос выглядит "как откомпилировать под некоторые классы типов" - то это вопрос уже специфичный. Можно применить жадное инстанцирование и не париться (но париться с раздутым объёмом сгенерированного кода), можно производить ленивую компиляцию on-demand, можно ещё много всего. КОнкретно llvm позволяет тебе пробовать любую схему не вдаваясь в дебри эффективной кодогенерации

zabivator
()

Читаем внимательно. This project is Google-financed, but not Google-owned. Реальные результаты могут быть. А могут и не быть.

Не все венчурные проекты даже солидных компаний выходят из стадии "прожектов".

------

Не тред, а инкубатор для откорма молодых троллей. Сильнее доставляет, чем "монти пайфон".

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

> Не тред, а инкубатор для откорма молодых троллей. Сильнее доставляет, чем "монти пайфон".

+1

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

> Реальные результаты могут быть. А могут и не быть.

И что? Это верно вообще для любого проекта. А эти по крайней мере поставили перед собой четкие задачи.

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

> Если же твой вопрос выглядит "как откомпилировать под некоторые классы типов" - то это вопрос уже специфичный. Можно применить жадное инстанцирование и не париться (но париться с раздутым объёмом сгенерированного кода), можно производить ленивую компиляцию on-demand, можно ещё много всего.

А можно и не париться со всеми этими сложностями: "we'll probably take each opcode and translate its ceval implementation into an IRBuilder implementation, but for difficult opcodes we could just emit calls to an interpretation function". %)

ч0рт, откуда же там 5-кратное ускорение...

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