В рамках проекта "newthreading (http://www.animats.com/papers/languages/newthreadingintro.html)" подготовлен (http://mail.python.org/pipermail/python-announce-list/2010-J...) прототип решения для добавления поддержки многопоточности в интерпретатор языка программирования Python, параллельное выполнение классов в котором ограничено из-за применения глобальной блокировки (GIL - Global Interpreter Lock). Начальная реализация технологии newthreading написана в виде модуля на языке Python и не обеспечивает заметного роста производительности, демонстрируя лишь принцип работы предложенной концепции.
API модуля "newthreading" включает реализацию функций стандартного модуля "threading", расширяя (http://www.animats.com/papers/languages/pythonconcurrency.html) их дополнительными средствами для организации синхронизации между параллельно выполняющимися классами. Модулем поддерживаются понятия "атомарный объект" и "синхронизированный объект", реализуемые через классы AtomicObject ...URL: http://mail.python.org/pipermail/python-announce-list/2010-J...
Новость: http://www.opennet.me/opennews/art.shtml?num=27107
Поправьте меня если я ошибаюсь, но когда эта фенечка будет реализована Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага? Люто бешено плюсую.
А как же perl?
Там эта многопоточность много-много лет уже!
осталось ещё {сборщик мусора} туда добавить :-) [впрочем в perl6 его таки добавили]# p.s.: {щётчик ссылок} это не {сборщик мусора}.
судя по shootout.alioth.debian.org с многопоточностью в perl-е не очень
Ссылку на тест многопоточности на shootout.alioth.debian.org
А чем конкретно вам так не угодил GIL?
Отсутствием возможность в одном процессе использовать имеющиеся 8+ голов. На С писать просто-напросто долго. При использовании fork (что на данный момент и делаю) необходимо взаимодествие через, например socketpair плюс не такая прозрачная логика.
по мне так -- использовать fork(..) напрямую -- не очень удобно......лучше модуль "multiprocessing" и ещё к нему + пару своих собственных костылей :-)
(например очень полезен класс Pipes (MyPipes), но с добавлением к нему той функциональности что -- при закрытии Pipes в одном проссе -- он автоматически [передавая соответствующщее "сообщение"] закрывается и в другом процессе)
(или ещё хорошобы добавить механизм, который обрабатывает сообщения от нескольких [вышеупомянутых] MyPipes -- при этом каждый экземпляр MyPipe способен склонировать себя для другого [нового] дружественного процесса, и также автоматически клон добавляется в обработку)
вообщем несколько разных костылей, и multiprocessing становиться вполне удобным инструментом! ничем не хуже чем многонитевость!
(((неговоря уже о том что даже во всяких Java и .NET, в которых многонитевость реализованна без GIL -- при вызывании сборщика мусора -- блокируется работат ВСЕХ нитей текущщего процесса!!)))
+1. Как только этот модуль начнет существовать в stable, его можно будет использовать :) А пока что fork() наше фсио.
>Как только этот модуль начнет существовать в stable, его можно будет
>использовать :)В каком stable? В Python 2.6.5 есть.
> Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага?SBCL, не?
GIL это особенность именно Python, в Perl (если мне не изменяет склероз), проблема сохранения целостности данных при использовании решена иначе. GIL это было удачное решение в те ещё времена, когда про многоядерность никто и не помышлял, да и многопроцессорность было явлением может и не таким уж редким, но как-то не пересекающимся с Python (а в случае пересечения используйте процессы и будет вам счастье, потоки, это для десктопов, это не по взрослому :-), сейчас же она мешает лишь использовать (ИНТЕРПРЕТАТОРУ, а нативные расширения никто не отменял) одновременно несколько ядер, это проблема в вычислительных задачах (где действительно нужены ресурсы CPU), но представить широкое применение Python в ним мне довольно сложно :-). Почему ещё GIL это может быть плохо. Многие хомячки (кстати, они сейчас поголовно делают для себя открытие -- асинхронное/событийное программирование) используют потоки и для одновременной обработки задач ввода-вывода (сеть, веб клиент-серверы и пр.), где абсолютно во всём выигрывает именно асинхронное решение (опять же, нет тонны потоков, нет "выдуманных" проблем с GIL). Конечно можно использовать потоки и для ввода-вывода, только нужно отдавать себе отчёт в своих действиях и понимать, что в случаях падения производительности, вы сам себе злобный буратино.p.s. Извините за много букв.
p.p.s. Я не говорю что GIL это хорошо и что проблема (если это для кого-то проблема) не достойна решения. Но как вы сами понимаете, лучшее враг хорошего. Может получиться так, что в 1 из 20 случаев будет 3х кратный прирост, а во всех остальных падение производительности на нцать процентов.
..bw
GIL приводит к поразительно высокому contention даже в коде, который написан с использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным в инете. Как только появляется несколько потоков, например, из-за используемых библиотек, так GIL сразу приводит к резкому падению производительности.
>GIL приводит к поразительно высокому contention даже в коде, который написан с
>использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным
>в инете. Как только появляется несколько потоков, например, из-за используемых библиотек,
>так GIL сразу приводит к резкому падению производительности.Python работает удивительно стабильно.. никаких кратвовременных зависаний в работе.. всё плавно и ПРЕДСКАЗУЕМО.
в Java и .NET (кроме кучи занятой памяти, о чём не будем говорить) -- постоянные предзависания! угадайте почему?
про Perl и говорить не стоит, язык не того уровня.. ещёбы bash вспомнилибы...
Perl действительно не того уровня - на голову выше
Perl действительно язык для тех, кто на голову ...
Почему питонисты такие ненавистники перла? Это что фанатизм, религия или просто свербит в одном месте от одного факта, что на перле тоже можно писать комфортно и удобно, и что правда он в чем-то может быть лучше питона.
Нормальный язык, лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально. Кстати баш, недавно пришлось пиасать на нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему сравнение его с перлом просто немуместно.
>Кстати баш, недавно пришлось пиасать на
>нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему
>сравнение его с перлом просто немуместно.еще и не очень партатабельно, если писать то на чистом sh
>лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально.
аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал, видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы решить мои задачи я должен установить целый ворох дополнительных p5-
>еще и не очень партатабельно, если писать то на чистом shСогласен, но на sh еще менее удобно, с удивлением обнаружил, то что на перле пишется легко и изящно, на шелле пришлось делать через глубокую задницу. Не знаю как народ осиливает огромные проекты на sh (etcnet, загрузочные скрипты BSD и т.д.)
>аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал,
>видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы
>решить мои задачи я должен установить целый ворох дополнительных p5-Зато у перла есть огромный cpan, где есть как и pure-perl модули, так и на с написанные.
Ну устанвливать, не так уж это и сложно.
Когда-нибудь доберусь до питона, как время будет, гляну эту хваленую стандартную библиотеку =)
Целиком и полностью согласен. Асинхронный подход это: экономия памяти, экономия на шедуле потоков/процессов, линейная логика, отсутствие дополнительных расходов на поддержании данных в консистентном состоянии.
Но! Хочется решения, когда мы в той же самой системе можем, при соотетствующем походе (сабж, указание критических классов) таки использовать настоящую многопоточность. Задачи поедающие CPU действительно решаются выносом в отдельный процесс/модуль, который уже написан на С/etc, но наличие решения для Python позволит расширить класс задач, которые можно таким (c module) образом не допиливать.На данный момент (из самого распространённого) быстрее только Lua, а больше библиотека только у Perl (сделайте меня развидеть его скорость, особенно обработке строк, sic!), т.ч. Python шагом к использованию настоящей многопоточности может завоевать ещё over 9000 программистов.
> На данный момент (из самого распространённого) быстрее только LuaPerl тоже быстрее.
И с многопоточностью никаких проблем
да proof же!?
> На данный момент (из самого распространённого) быстрее только LuaГде пруф?!!!!!!!!!
http://shootout.alioth.debian.org
Этот пруф я знаю.
Только там ничего нет про то, что якобы "перл на n-камней с трудом догоняет Питон на одном"
Правильно! Там есть Питон на любой комбинации камней \ 32/64 bit \ с трэдами или без рвёт :W скъюзьмуа - обходит Перл по всем параметрам :)Ну а если не троллить :) - то они приблизительно одного поля ягоды. И луа - там же.
многопоточном в одном процессе нужна лишь на винде, там создание нового процесса тормозная операция