Google's Python engineers have launched a new project called Unladen Swallow, which aims to bring a major performance boost to the Python programming language by making runtime speed five times faster. The project is being implemented as a branch of the conventional CPython runtime and will be fully source-compatible with regular Python applications and native extensions.

The goal of the Unladen Swallow project is to use LLVM, the Low Level Virtual Machine compiler infrastructure, to build a just-in-time (JIT) compilation engine that can replace Python's own specialized virtual machine.

link

Еще бы GIL убрали и вообще будет замечательно.

они hope.

They are very serious about fixing multithreading in Python and hope to slay the Global Interpreter Lock

slivlen
Еще бы GIL убрали и вообще будет замечательно.

Кому будет?:-)

Физически невозможно. Прочитал и продебажил все исходники Питона. GIL - порождение концепции этого языка. Более менее радикальным решением был подход Stackless - но его не приняли в семейство змеюк, за хак в переключении фреймов стека. VM питона можно ускорить, но без потери динамики, весьма незначительно - раза в полтора. Но и это не детский фокус. Так-что, ИМХО, можно смело забить на эти слухи. А с потерей динамики - это уже в “психо” делали - этакое толкование, но как и Stackless - на любителя. :(

если серьезно возьмутся - то почему бы и нет (это я про убирание ГИЛа, ведь убирали же =).

просто современный “мультитрединг” с pyprocessing - это же вообще ахтунг, так распараллеливать можно и без него - пиши себе программу запускающую отдельные куски в разных интерпретаторах (может я конечно не так понял фишку), путем переделывания под многопроцессорность - эту самую многопроцессорность можно получить, я хочется из коробки.
а stackless походу очень юзает MPI

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

я конечно не спец по исходникам CPython, но почему то кажется, что если один раз написали это, то может и еще раз можно повторить шедевр, были бы деньги, время и программисты =) хотя я может путаю концепции языка и самого CPython? просто сделали же IronPython… и там тру-многопоточность

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

Я так зрозумів, гугл хоче зробити за принципом як в MacRuby зроблено для рубі … в принципі тоді пришвидшення можливе.

GIL убирали - вышло на 25% медленней + дополнительный финализатор + проблемы с GC + не все работало
А еще прийдется переписать все C extension (или сильно усложнить интерпритатор, разделив расширения на “опасные” и “безопасные”).
Получится немного другой язык.
Разделение на процессы легче. И безопасней (поломается один - другие выживут).

Ускорение в пять раз - под вопросов. На днях Флетчер на лекции по оптимизации говорил, что Питон примерно в 10 раз медленней С. Судя по тому, что помидорами в него не кидались - не соврал. Чтобы разница стала всего в два раза - не верю. Совсем. Но определенный прирост в скорости может быть, конечно.

Кстати, вчера ребята из ccp games обещали, что через пару недель в Open Source выйдет их StacklessIO - высокопроизводительная библиотека ввода-вывода (WIndows support only for now).

5-кратный прирост скорости вполне обоснован, т.к. планируется в интерпретатор встроить JIT компиллятор:

Dmitrey
Our long-term proposal is to replace CPython's custom virtual machine with a JIT built on top of LLVM, while leaving the rest of the Python runtime relatively intact.

И psyco в данном случае дает оценку прироста:

2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.