форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

Сообщения по теме

[Сортировка по ответам | RSS]

	1. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от brzm on 26-Июн-10, 11:54
	Поправьте меня если я ошибаюсь, но когда эта фенечка будет реализована Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага? Люто бешено плюсую.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Проект по интеграции поддержки многопоточности в Python и ре..."	+2 +/–
	Сообщение от аноним on 26-Июн-10, 12:13
	А как же perl? Там эта многопоточность много-много лет уже!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от Аноним (??) on 26-Июн-10, 12:33
	А чем конкретно вам так не угодил GIL?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "RTFM"	+5 +/–
	Сообщение от bw (??) on 26-Июн-10, 13:49
	GIL это особенность именно Python, в Perl (если мне не изменяет склероз), проблема сохранения целостности данных при использовании решена иначе. GIL это было удачное решение в те ещё времена, когда про многоядерность никто и не помышлял, да и многопроцессорность было явлением может и не таким уж редким, но как-то не пересекающимся с Python (а в случае пересечения используйте процессы и будет вам счастье, потоки, это для десктопов, это не по взрослому :-), сейчас же она мешает лишь использовать (ИНТЕРПРЕТАТОРУ, а нативные расширения никто не отменял) одновременно несколько ядер, это проблема в вычислительных задачах (где действительно нужены ресурсы CPU), но представить широкое применение Python в ним мне довольно сложно :-). Почему ещё GIL это может быть плохо. Многие хомячки (кстати, они сейчас поголовно делают для себя открытие -- асинхронное/событийное программирование) используют потоки и для одновременной обработки задач ввода-вывода (сеть, веб клиент-серверы и пр.), где абсолютно во всём выигрывает именно асинхронное решение (опять же, нет тонны потоков, нет "выдуманных" проблем с GIL). Конечно можно использовать потоки и для ввода-вывода, только нужно отдавать себе отчёт в своих действиях и понимать, что в случаях падения производительности, вы сам себе злобный буратино. p.s. Извините за много букв. p.p.s. Я не говорю что GIL это хорошо и что проблема (если это для кого-то проблема) не достойна решения. Но как вы сами понимаете, лучшее враг хорошего. Может получиться так, что в 1 из 20 случаев будет 3х кратный прирост, а во всех остальных падение производительности на нцать процентов. ..bw
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "RTFM"	+/–
	Сообщение от kkk (??) on 26-Июн-10, 14:26
	GIL приводит к поразительно высокому contention даже в коде, который написан с использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным в инете. Как только появляется несколько потоков, например, из-за используемых библиотек, так GIL сразу приводит к резкому падению производительности.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от brzm on 26-Июн-10, 16:46
	Отсутствием возможность в одном процессе использовать имеющиеся 8+ голов. На С писать просто-напросто долго. При использовании fork (что на данный момент и делаю) необходимо взаимодествие через, например socketpair плюс не такая прозрачная логика.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от Имя123321 on 26-Июн-10, 16:48
	осталось ещё {сборщик мусора} туда добавить :-) [впрочем в perl6 его таки добавили] # p.s.: {щётчик ссылок} это не {сборщик мусора}.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Проект по интеграции поддержки многопоточности в Python и ре..."	–1 +/–
	Сообщение от Имя123321 on 26-Июн-10, 16:56
	по мне так -- использовать fork(..) напрямую -- не очень удобно... ...лучше модуль "multiprocessing" и ещё к нему + пару своих собственных костылей :-) (например очень полезен класс Pipes (MyPipes), но с добавлением к нему той функциональности что -- при закрытии Pipes в одном проссе -- он автоматически [передавая соответствующщее "сообщение"] закрывается и в другом процессе) (или ещё хорошобы добавить механизм, который обрабатывает сообщения от нескольких [вышеупомянутых] MyPipes -- при этом каждый экземпляр MyPipe способен склонировать себя для другого [нового] дружественного процесса, и также автоматически клон добавляется в обработку) вообщем несколько разных костылей, и multiprocessing становиться вполне удобным инструментом! ничем не хуже чем многонитевость! (((неговоря уже о том что даже во всяких Java и .NET, в которых многонитевость реализованна без GIL -- при вызывании сборщика мусора -- блокируется работат ВСЕХ нитей текущщего процесса!!)))
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "RTFM"	+/–
	Сообщение от brzm on 26-Июн-10, 17:03
	Целиком и полностью согласен. Асинхронный подход это: экономия памяти, экономия на шедуле потоков/процессов, линейная логика, отсутствие дополнительных расходов на поддержании данных в консистентном состоянии. Но! Хочется решения, когда мы в той же самой системе можем, при соотетствующем походе (сабж, указание критических классов) таки использовать настоящую многопоточность. Задачи поедающие CPU действительно решаются выносом в отдельный процесс/модуль, который уже написан на С/etc, но наличие решения для Python позволит расширить класс задач, которые можно таким (c module) образом не допиливать. На данный момент (из самого распространённого) быстрее только Lua, а больше библиотека только у Perl (сделайте меня развидеть его скорость, особенно обработке строк, sic!), т.ч. Python шагом к использованию настоящей многопоточности может завоевать ещё over 9000 программистов.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "RTFM"	+/–
	Сообщение от Имя123321 on 26-Июн-10, 17:06
	>GIL приводит к поразительно высокому contention даже в коде, который написан с >использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным >в инете. Как только появляется несколько потоков, например, из-за используемых библиотек, >так GIL сразу приводит к резкому падению производительности. Python работает удивительно стабильно.. никаких кратвовременных зависаний в работе.. всё плавно и ПРЕДСКАЗУЕМО. в Java и .NET (кроме кучи занятой памяти, о чём не будем говорить) -- постоянные предзависания! угадайте почему? про Perl и говорить не стоит, язык не того уровня.. ещёбы bash вспомнилибы...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от brzm on 26-Июн-10, 17:10
	+1. Как только этот модуль начнет существовать в stable, его можно будет использовать :) А пока что fork() наше фсио.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "RTFM"	–1 +/–
	Сообщение от аноним on 26-Июн-10, 17:46
	Perl действительно не того уровня - на голову выше
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "RTFM"	–1 +/–
	Сообщение от аноним on 26-Июн-10, 17:47
	> На данный момент (из самого распространённого) быстрее только Lua Perl тоже быстрее. И с многопоточностью никаких проблем
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "RTFM"	+1 +/–
	Сообщение от brzm on 26-Июн-10, 17:59
	да proof же!?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от анонимус (??) on 26-Июн-10, 18:13
	> Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага? SBCL, не?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "RTFM"	+1 +/–
	Сообщение от аноним on 26-Июн-10, 18:21
	> На данный момент (из самого распространённого) быстрее только Lua Где пруф?!!!!!!!!!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "STFW"	–1 +/–
	Сообщение от Аноним (??) on 26-Июн-10, 19:10
	http://shootout.alioth.debian.org
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "STFW"	+1 +/–
	Сообщение от аноним on 26-Июн-10, 19:32
	Этот пруф я знаю. Только там ничего нет про то, что якобы "перл на n-камней с трудом догоняет Питон на одном"
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от hizel (ok) on 26-Июн-10, 22:07
	судя по shootout.alioth.debian.org с многопоточностью в perl-е не очень
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от аноним on 27-Июн-10, 00:24
	>Как только этот модуль начнет существовать в stable, его можно будет >использовать :) В каком stable? В Python 2.6.5 есть.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "RTFM"	–1 +/–
	Сообщение от СуперАноним on 27-Июн-10, 09:19
	Perl действительно язык для тех, кто на голову ...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от аноним on 27-Июн-10, 10:09
	Ссылку на тест многопоточности на  shootout.alioth.debian.org
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "Проект по интеграции поддержки многопоточности в Python и ре..."	+/–
	Сообщение от Аноним (??) on 27-Июн-10, 12:27
	многопоточном в одном процессе нужна лишь на винде, там создание нового процесса тормозная операция
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "STFW"	+/–
	Сообщение от аноним on 28-Июн-10, 17:37
	Правильно! Там есть Питон на любой комбинации камней \ 32/64 bit \ с трэдами или без рвёт :W скъюзьмуа - обходит Перл по всем параметрам :) Ну а если не троллить :) - то они приблизительно одного поля ягоды. И луа - там же.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "RTFM"	+/–
	Сообщение от Sugar (ok) on 30-Июн-10, 11:28
	Почему питонисты такие ненавистники перла? Это что фанатизм, религия или просто свербит в одном месте от одного факта, что на перле тоже можно писать комфортно и удобно, и что правда он в чем-то может быть лучше питона. Нормальный язык, лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально. Кстати баш, недавно пришлось пиасать на нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему сравнение его с перлом просто немуместно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "RTFM"	+/–
	Сообщение от hizel (ok) on 30-Июн-10, 11:38
	>Кстати баш, недавно пришлось пиасать на >нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему >сравнение его с перлом просто немуместно. еще и не очень партатабельно, если писать то на чистом sh >лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально. аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал, видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы решить мои задачи я должен установить целый ворох дополнительных p5-
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "RTFM"	+/–
	Сообщение от Sugar (ok) on 30-Июн-10, 13:04
	>еще и не очень партатабельно, если писать то на чистом sh Согласен, но на sh еще менее удобно, с удивлением обнаружил, то что на перле пишется легко и изящно, на шелле пришлось делать через глубокую задницу. Не знаю как народ осиливает огромные проекты на sh (etcnet, загрузочные скрипты BSD и т.д.) >аналогично, только для пистона, ибо стандартная библиотека там выше всяких похвал, >видимо сказывается удобство написания расширений на Си по пистон, а в перле чтобы >решить мои задачи я должен установить целый ворох дополнительных p5- Зато у перла есть огромный cpan, где есть как и pure-perl модули, так и на с написанные. Ну устанвливать, не так уж это и сложно. Когда-нибудь доберусь до питона, как время будет, гляну эту хваленую стандартную библиотеку =)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема