| 1.1, brzm (?), 11:54, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Поправьте меня если я ошибаюсь, но когда эта фенечка будет реализована Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага? Люто бешено плюсую.
| | |
| |
| 2.2, аноним (?), 12:13, 26/06/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
А как же perl?
Там эта многопоточность много-много лет уже!
| | |
| |
| 3.9, Имя123321 (?), 16:48, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
осталось ещё {сборщик мусора} туда добавить :-) [впрочем в perl6 его таки добавили]
# p.s.: {щётчик ссылок} это не {сборщик мусора}.
| | |
| 3.26, hizel (ok), 22:07, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
 судя по shootout.alioth.debian.org с многопоточностью в perl-е не очень
| | |
|
| |
| 3.8, brzm (?), 16:46, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
Отсутствием возможность в одном процессе использовать имеющиеся 8+ голов. На С писать просто-напросто долго. При использовании fork (что на данный момент и делаю) необходимо взаимодествие через, например socketpair плюс не такая прозрачная логика.
| | |
| |
| 4.11, Имя123321 (?), 16:56, 26/06/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
по мне так -- использовать fork(..) напрямую -- не очень удобно...
...лучше модуль "multiprocessing" и ещё к нему + пару своих собственных костылей :-)
(например очень полезен класс Pipes (MyPipes), но с добавлением к нему той функциональности что -- при закрытии Pipes в одном проссе -- он автоматически [передавая соответствующщее "сообщение"] закрывается и в другом процессе)
(или ещё хорошобы добавить механизм, который обрабатывает сообщения от нескольких [вышеупомянутых] MyPipes -- при этом каждый экземпляр MyPipe способен склонировать себя для другого [нового] дружественного процесса, и также автоматически клон добавляется в обработку)
вообщем несколько разных костылей, и multiprocessing становиться вполне удобным инструментом! ничем не хуже чем многонитевость!
(((неговоря уже о том что даже во всяких Java и .NET, в которых многонитевость реализованна без GIL -- при вызывании сборщика мусора -- блокируется работат ВСЕХ нитей текущщего процесса!!)))
| | |
| |
| 5.15, brzm (?), 17:10, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
+1. Как только этот модуль начнет существовать в stable, его можно будет использовать :) А пока что fork() наше фсио.
| | |
| |
| 6.27, аноним (?), 00:24, 27/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Как только этот модуль начнет существовать в stable, его можно будет
>использовать :)
В каком stable? В Python 2.6.5 есть.
| | |
|
|
|
|
| 2.22, анонимус (??), 18:13, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага?
SBCL, не?
| | |
|
| 1.4, bw (??), 13:49, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 GIL это особенность именно Python, в Perl (если мне не изменяет склероз), проблема сохранения целостности данных при использовании решена иначе. GIL это было удачное решение в те ещё времена, когда про многоядерность никто и не помышлял, да и многопроцессорность было явлением может и не таким уж редким, но как-то не пересекающимся с Python (а в случае пересечения используйте процессы и будет вам счастье, потоки, это для десктопов, это не по взрослому :-), сейчас же она мешает лишь использовать (ИНТЕРПРЕТАТОРУ, а нативные расширения никто не отменял) одновременно несколько ядер, это проблема в вычислительных задачах (где действительно нужены ресурсы CPU), но представить широкое применение Python в ним мне довольно сложно :-). Почему ещё GIL это может быть плохо. Многие хомячки (кстати, они сейчас поголовно делают для себя открытие -- асинхронное/событийное программирование) используют потоки и для одновременной обработки задач ввода-вывода (сеть, веб клиент-серверы и пр.), где абсолютно во всём выигрывает именно асинхронное решение (опять же, нет тонны потоков, нет "выдуманных" проблем с GIL). Конечно можно использовать потоки и для ввода-вывода, только нужно отдавать себе отчёт в своих действиях и понимать, что в случаях падения производительности, вы сам себе злобный буратино.
p.s. Извините за много букв.
p.p.s. Я не говорю что GIL это хорошо и что проблема (если это для кого-то проблема) не достойна решения. Но как вы сами понимаете, лучшее враг хорошего. Может получиться так, что в 1 из 20 случаев будет 3х кратный прирост, а во всех остальных падение производительности на нцать процентов.
..bw
| | |
| |
| 2.5, kkk (??), 14:26, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
GIL приводит к поразительно высокому contention даже в коде, который написан с использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным в инете. Как только появляется несколько потоков, например, из-за используемых библиотек, так GIL сразу приводит к резкому падению производительности.
| | |
| |
| 3.14, Имя123321 (?), 17:06, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>GIL приводит к поразительно высокому contention даже в коде, который написан с
>использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным
>в инете. Как только появляется несколько потоков, например, из-за используемых библиотек,
>так GIL сразу приводит к резкому падению производительности.
Python работает удивительно стабильно.. никаких кратвовременных зависаний в работе.. всё плавно и ПРЕДСКАЗУЕМО.
в Java и .NET (кроме кучи занятой памяти, о чём не будем говорить) -- постоянные предзависания! угадайте почему?
про Perl и говорить не стоит, язык не того уровня.. ещёбы bash вспомнилибы...
| | |
| |
| 4.32, Sugar (ok), 11:28, 30/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Почему питонисты такие ненавистники перла? Это что фанатизм, религия или просто свербит в одном месте от одного факта, что на перле тоже можно писать комфортно и удобно, и что правда он в чем-то может быть лучше питона.
Нормальный язык, лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально. Кстати баш, недавно пришлось пиасать на нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему сравнение его с перлом просто немуместно.
| | |
| |
| 5.33, hizel (ok), 11:38, 30/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Кстати баш, недавно пришлось пиасать на
>нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему
>сравнение его с перлом просто немуместно.
еще и не очень партатабельно, если писать то на чистом sh
>лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально.
аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал, видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы решить мои задачи я должен установить целый ворох дополнительных p5-
| | |
| |
| 6.34, Sugar (ok), 13:04, 30/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>еще и не очень партатабельно, если писать то на чистом sh
Согласен, но на sh еще менее удобно, с удивлением обнаружил, то что на перле пишется легко и изящно, на шелле пришлось делать через глубокую задницу. Не знаю как народ осиливает огромные проекты на sh (etcnet, загрузочные скрипты BSD и т.д.)
>аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал,
>видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы
>решить мои задачи я должен установить целый ворох дополнительных p5-
Зато у перла есть огромный cpan, где есть как и pure-perl модули, так и на с написанные.
Ну устанвливать, не так уж это и сложно.
Когда-нибудь доберусь до питона, как время будет, гляну эту хваленую стандартную библиотеку =)
| | |
|
|
|
|
| 2.12, brzm (?), 17:03, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
Целиком и полностью согласен. Асинхронный подход это: экономия памяти, экономия на шедуле потоков/процессов, линейная логика, отсутствие дополнительных расходов на поддержании данных в консистентном состоянии.
Но! Хочется решения, когда мы в той же самой системе можем, при соотетствующем походе (сабж, указание критических классов) таки использовать настоящую многопоточность. Задачи поедающие CPU действительно решаются выносом в отдельный процесс/модуль, который уже написан на С/etc, но наличие решения для Python позволит расширить класс задач, которые можно таким (c module) образом не допиливать.
На данный момент (из самого распространённого) быстрее только Lua, а больше библиотека только у Perl (сделайте меня развидеть его скорость, особенно обработке строк, sic!), т.ч. Python шагом к использованию настоящей многопоточности может завоевать ещё over 9000 программистов.
| | |
| |
| 3.18, аноним (?), 17:47, 26/06/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> На данный момент (из самого распространённого) быстрее только Lua
Perl тоже быстрее.
И с многопоточностью никаких проблем
| | |
| |
| |
| 5.23, аноним (?), 18:21, 26/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> На данный момент (из самого распространённого) быстрее только Lua
Где пруф?!!!!!!!!!
| | |
| |
| |
| 7.25, аноним (?), 19:32, 26/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Этот пруф я знаю.
Только там ничего нет про то, что якобы "перл на n-камней с трудом догоняет Питон на одном"
| | |
|
|
|
|
|
|
| 1.30, Аноним (-), 12:27, 27/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
многопоточном в одном процессе нужна лишь на винде, там создание нового процесса тормозная операция
| | |
|
