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

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

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

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

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

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

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

Я тоже думаю, что пока питоноводы не научатся делать type inference приемлемого качества, о скорости можно забыть.

З.Ы. Прочитав посты забиватора, мне тоже очень захотелось написать что-то такое:

Я знаю дзюдо! Тэйквондо!! Карате!!!

и много других страшных слов...

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

> В одних задачаз не требуется code security, в других - нет ... Для некоторых задач может быть более оправдан выбор VM пусть стековой, пусть без предкомпиляции, но с защитой кода. (понятно, о какой вм идет речь. Да и об автоматическом управленни памятью иногда стОит подумать.)

Нет, я так и не понял... Если ты о виртуальной машине явы -- так она тащит с собой 37 мегов Дырявого И Тормозоного Кода На Опасном Языке С(С++), так что о какой безопасности может идти речь?

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

>только мне в новости читается "Бин Ладен" ? )))

не. у меня такой же бзик:D

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

>Именно в этом вся сложность задачи.

Ну вкомпилируют они все проверки даже без всякого inference - всё равно быстрее будет чем сейчас. В чём твоя проблема то ? Runtime специализацию тоже может сделают. В llvm кажется обещали hotspotting.

С другой стороны отвратительно что из-за *анной базы экстеншеннов убить reference сounting и заменить его на нормальный gc - им не удастся. И это в уже конец первого десятилетия 21ого века...

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

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

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

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

> Ну вкомпилируют они все проверки даже без всякого inference - всё равно быстрее будет чем сейчас

Ну если ты обещаешь, тогда я спокоен. Они, правда, говорят об ускорении на 10-25%, но тебе виднее.

> В чём твоя проблема то ?

Ты психоаналитег? А проблема обсуждаемого проекта - в том, что из приведенных по линкам чисел не получается 5-кратного ускорения.

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

Кстати, за оставление reference counting еще значительное число неявного использования его в виде open('blabla').read() и подобных функций.

А вообще, чем так сильно reference counting не угодил? Для меня, как простого пользователя питона, это наименьшая из его проблем, связанных с производительностью :))

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

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

>на, почитай http://www.python.ru/files/book-ods.pdf

:) хорошая книга - с нее изучил основы, а дальше pydoc

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

> А что не так с регулярными выражениями?

>> We plan to address performance considerations in the regular expression engine, as well as any other extension modules found to be bottlenecks. However, regular expressions are already known to be a good target for our work and will be considered first for optimization.

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

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

Юным питонистам?

> Google's Python engineers have launched a new project called Unladen Swallow that seeks to improve the performance of the Python programming language. One of the project's goals is to replace the Python virtual machine with an LLVM-based JIT.

> Google's Python engineers

> Google's Python engineers

> Google's Python engineers

http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-bo...

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

> Теперь Веснот пернстанет тормозить на моём ноуте?

А они перешли на питоновский AI как на основной?

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

> http://swtch.com/~rsc/regexp/regexp1.html

Возможно всё дело в том, что Regular expression search algorithm Томпсона был запатентован. Вот все по традиции и боятся его использовать, хотя срок у патента уже вышел.

Regular expressions were invented by Stephen Kleene in the mid-1950's as a notation for finite automata, and in fact they are equivalent to finite automata in what they represent. Regular expressions first appeared in a program setting in Ken Thompson's version of the QED text editor in the mid-1960's. In 1967, Ken applied for a patent on a mechanism for rapid text matching based on regular expressions; it was granted in 1971, one of the very first software patents [US Patent 3,568,156, Text Matching Algorithm, March 2, 1971].

Вот так то!

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

> Спасибо за ссылку на диалоги, повеселился в очередной раз.

Дважды спасибо и от меня :)

В фильме эпизод вообще бешеный

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

> Возможно всё дело в том, что Regular expression search algorithm Томпсона был запатентован. Вот все по традиции и боятся его использовать, хотя срок у патента уже вышел.

Почему тогда awk, grep и компания не боятся? Может я что-то не так понял.

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

гугл никогда их и не жаловал, насколько я знаю...

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

> > А что не так с регулярными выражениями?

> http://swtch.com/~rsc/regexp/regexp1.html

Ух ты, какая правильная ссылка! А откуда уверенность, что работа предстоит именно в направлении, указанном в статье? В топовой ссылке на подробности ничего не сказано про выпиливание "back references" из питоновских регэкспов.

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

> А откуда уверенность, что работа предстоит именно в направлении, указанном в статье?

Я этого не говорил и, честно говоря, не в курсе, что там за работа предстоит.

А ссылка из википедии. Там еще есть, если нужно.

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

> Почему тогда awk, grep и компания не боятся? Может я что-то не так понял.

AWK написан корешем Томпсона из той же организации (K -- Керниган), grep -- тоже, ну а GNU Grep -- по инерции.

sv75 ★★★★★
()

круто
это вам не шестой перл

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