[python][PyPy] GIL-капец :)

>Типа если две(а то и более) транзакции наложились то first wins, остальные «откытываются»(а на самом деле просто тупо прибиваются) и код переисполняется.

Круто.

Ну, вообще-то они пока ничего не решили. Но было бы прикольно, да. Можно было бы троллить хаскелляторов.

У них тоже есть GIL?

У них тоже есть GIL?

У них уже реализовано то что хотят сделать в PyPy.

PS новость забомбил: Реализация PyPy языка Python избавляется от глобальных блокировок

> У них тоже есть GIL?

Они придумали STM, но, AFAIK, в RTS его нет.

хм.. разве хаскеллисты придумали STM?..

Они придумали STM

Что-то английская википедия молчит по этому поводу :). Пишут что впервые эта техника была предложена в 1995-м by Nir Shavit and Dan Touitou. Что-то я не вижу чтобы эти чуваки были в списке разрабов хаскеля :)

Они ж сами ожидают, что на одном потоке STM будет в 2-5 раз медленнее, чем GIL.

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

Нафига козе бопитону истинная параллельность без GIL?

Нафига

чтобы загрузить все ядра проца :).

> хм.. разве хаскеллисты придумали STM?..

Не придумали, так популяризировали.

Они придумали STM, но, AFAIK, в RTS его нет.

STM for Haskell was first implemented in GHC 6.4

что значит - нет в RTS?

Никогда не понимал зачем его изначально добавляли. В Java/.NET такого нет, почему?

А чем там троллить-то? Лично я буду исключительно рад, если STM найдет применение в PyPy. Например, в сишарпах же его запилить так и не смогли.

Питон и так тормозной, а накладные расходы на синхронизацию потоков его еще сильнее тормознут.

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

Лично я буду исключительно рад, если STM найдет применение в PyPy

+1

> Питон и так тормозной

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

С чем ты не согласен?

> С чем ты не согласен?

Вот с этим:

elverion> Питон и так тормозной

Тормозными бывают не сами языки, а конкретные реализации языка (и даже при этом зависит от задачи).

elverion> накладные расходы на синхронизацию потоков его еще сильнее тормознут

Тормознут по сравнению с чем? Да и вообще, время покажет.

чтобы загрузить все ядра проца :).

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

Никогда не понимал зачем его изначально добавляли. В Java/.NET такого нет, почему?

Потому, что thread-safe VM написать сильно сложнее.

Я так и подумал

А что будет если юзать Python в качестве embedded языка в могопоточное С++ приложение?

зачем его изначально добавляли

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

Не думаю, что питон удачный выбор для встраивания. Но немного по другой причине. На сколько я знаю, тот же lua имеет GIL, но он per-vm, а у питона per-process GIL. Поэтому для lua можно в каждом треде создавать по инстансу vm. С питоном такое нельзя. То есть сторого говоря, GIL не является помехой для встраивания.

Получается JS наше все

Замечание про pev-vm GIL верное, питон умеет только «один раз встроиться». Но я не знаю случаев когда это было бы сильно проблемой.

>Не думаю, что питон удачный выбор для встраивания.

Lua тоже не сахар. Вон, известный писатель на lua (а также автор awesome и xcb) хорошо про это написал:

http://julien.danjou.info/blog/2011.html#Why_not_Lua

Самое хреновое, что придется переписать все питоновские библиотеки с таким подходом.

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

> придется переписать все питоновские библиотеки с таким подходом.

Зачем?

Ну в том примере, который в блоге, у всех методов появляется дополнительный аргумент с транзакцией.

> Ну в том примере, который в блоге, у всех методов появляется дополнительный аргумент с транзакцией.

Это только иллюстрация.

Да фиг знает, особо не копал в эту сторону. Но lua выглядит чертовски привлекательным как язык. По производительности оно (lua-jit) примерно схожее c v8. И да, видимо для встраивания поддержка многопоточности не очень нужна.

В Java встроен Rhino, потому там проблемы с многопоточностью решены сразу на уровне потоков VM. Хотя не уверен что работает так же быстро как V8

Я все же не до конца понимаю в чем проблема. Нафига в каких-то скриптиках-расширения настоящие треды?

Пример идеи в моем личном проекте. Я хочу администрирование серверного приложения сделать на JavaScript. Тоесть некоторые глобальные вещи по обработке данных будут валидироваться в JS функции, которую можно будет забросить в специальную папку. Искаропки возможность применить логику исследовать обьекты статистики, передаваемые внутрь, для принятия решения.

Ну и зачем оно надо? Сам же Гвидо вроде как-то говорил, что GIL не уберем, пока не найдется альтернатива, не замедляющая однопоточные программы. Здесь эта проблема не решена. Ну и толку с этого?

Казалось бы, при чем тут Гвидо?

А если на питоне верхний слой, а внизу so-шки из С собранные, можно будет в нескольких потоках пускать С-шные функции?

Нет. По крайней мере, не автоматически.

Нафига в каких-то скриптиках-расширения

Потому что не только «скриптики» на нём делаются.

настоящие треды?

Они там и так настоящие.

можно будет в нескольких потоках пускать С-шные функции?

без проблем, правило тут только одно: В cpython интерпретатор байткода должен работать только в одном треде. Других ограничений нет со стороны cpython нет.

Ну и зачем оно надо?

чтобы работало быстрее

Сам же Гвидо вроде как-то говорил

А тут речь не о cpython, а о PyPy.

Здесь эта проблема не решена.

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

Потому что не только «скриптики» на нём делаются.

Ну так никто и не привел пример задачи где без тредов без GIL ну вообще никак.

Они там и так настоящие.

Да знаю я :)

Ну так никто и не привел пример задачи где без тредов без GIL ну вообще никак.

Пример: многопоточный сервер на сервере с несколькими ядрами.

Оно уже научилось само собираться без 4 гигов памяти ? Это какой то пипец, а не питон :-)

> Оно уже научилось само собираться без 4 гигов памяти ?

Давно уже.

Сколько сейчас надо ?