Python-сообщество

> на делфях
:)

lorien
> Краеугольный камень срача “треды vs кооперативная многозадачность”.
Вы заблуждаетесь, я не учавствую в сраче. Просто рекомендую использовать асинхронность т.к. она меньше систему грузит. Если вам нравится использовать треды, ради бога.

А на чем основана эта рекомендация? Есть тесты, на каком количестве соединений насколько меньше они грузят? Или это такое внутреннее чувство? :)

А недостатки у кооперативной многозадачности есть: во-первых, для него нужен специальный фреймверк, и во-вторых, все операции должны выполняться “мгновенно”. Если Вы парсите документ и парсинг занимает секунду, то эту секунду все потоки будут отдыхать. При многопоточности они бы занимались своим делом.

asilyator
> на делфях
:)

И чо? На питоне он насколько больше?

Отредактировано asilyator (Июнь 14, 2012 13:15:44)

asilyator
А на чем основана эта рекомендация? Есть тесты, на каком количестве соединений насколько меньше они грузят? Или это такое внутреннее чувство? :)

На самом деле не так страшен груз, как переключение контекста: http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82%D0%B0

asilyator
Что многотредовое приложение на питоне не будет работать быстрее на многоядернике, чем на одноядернике с такой же частотой?

в рамках 1 процесса - нет

asilyator
Ты две строчки способен прочесть?
Я написал о том, что даже на 500 тредах оверхед (правда, в приложении на делфях) абсолютно минимальный

ах, так мы про Delphi!

Вообще темы про “мне надо мульйон тредов, а питон гавно!” уже не раз обсуждались. Более того, сомневаюсь что 500 тредов, у тебя удачно стартанут без увеличения thread stack size, хотя может в последних версиях что-то поменялось.

Отредактировано slav0nic (Июнь 14, 2012 13:24:54)

> А на чем основана эта рекомендация? Есть тесты, на каком количестве соединений насколько меньше они грузят? Или это такое внутреннее чувство? :)
Ну скажем так, система раком вставала на сотнях тредах. Когда я использую сотни сетевых потоков, я вообще этого не замечаю.

> во-первых, для него нужен специальный фреймверк
Поэтому и был написан Grab:Spider - он действительно позволяет писать парсеры легко и непринуждённо. Ну или scrapy - там такая же архитектура.

> и во-вторых, все операции должны выполняться “мгновенно”. Если Вы парсите документ и парсинг занимает секунду, то эту секунду все потоки будут отдыхать. При многопоточности они бы занимались своим делом.
Чтобы парсинг занимал секунду, надо парсить *очень* большой документ. Среднее время парсинга документа на порядки меньше. Для ускорения парсинга имеет смысл разбросать на несколько процессов (по количеств ядер), но это усложняет логику программы (или фреймворка) и обычно хватает работы на одном ядре.

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

asilyator
Если Вы парсите документ и парсинг занимает секунду, то эту секунду все потоки будут отдыхать. При многопоточности они бы занимались своим делом.

Треды в основном полезны при больших IO, где велико ожидание ответа, аля запрос по сети и так далее, но твои размышления не совсем верны)

lorien
Ну скажем так, система раком вставала на сотнях тредах.

Тут проблема должна быть в чем-то другом. Код можно?

lorien
> во-первых, для него нужен специальный фреймверк
Поэтому и был написан Grab:Spider - он действительно позволяет писать парсеры легко и непринуждённо. Ну или scrapy - там такая же архитектура.

Я про что-то вроде Twisted, где можно, например, делать паузу.

lorien
Чтобы парсинг занимал секунду, надо парсить *очень* большой документ.

У меня построение дерева с помощью html5lib где-то столько занимает на вполне обычной странице.
Вполне может так получиться, что у разработчика фсе работает, а у клиента внезапно какая-то операция занимает слишком много и из за этого тормозятся другие потоки.
Кооперативная многозадачность - не серебрянная пуля. Кто-то хочет меня переубедить?

slav0nic
ах, так мы про Delphi!

А в питоне оно принципилально по другому? Питонкапец++ :) Хотя надо проверить. Код можно?

slav0nic
asilyator
Что многотредовое приложение на питоне не будет работать быстрее на многоядернике, чем на одноядернике с такой же частотой?


в рамках 1 процесса - нет

А что ты хотел этим сказать? Не понял.

slav0nic
asilyator
Не говоря о том, что треды лучше параллелятся (для питона неактулально).


смелое утверждение %) очередное горе от ума и не понимание GIL в полной мере.

slav0nic
Треды в основном полезны при больших IO, где велико ожидание ответа, аля запрос по сети и так далее, но твои размышления не совсем верны)

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

Отредактировано asilyator (Июнь 14, 2012 13:36:11)

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

asilyator
А в питоне оно принципилально по другому?

Я же написал, прочитай что такое GIL и как он связан с потоками и сколько native потоков могут работать одновременно и как происходит переключение между потоками (то что regall
кидал например)

Ну и питон как бы интерпретатор… конечно по другому

asilyator
А что ты хотел этим сказать? Не понял.

то что для 400% загрузки 4 CPU надо запустить 4 процесса для начала, а 100 тредов тебе все ресурсы CPU не выжрут, это по-моему даже в доке описано, но другими словами)

Отредактировано slav0nic (Июнь 14, 2012 13:38:36)

lorien
Треды могут быть полезны в задачах, которые трудно разбить на относительно маленькие синхронные кусочки. Тогда пишем треды и не паримся, что у нас всё зависнте из-за долгого синхронного кусочка.

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

slav0nic
asilyator
А в питоне оно принципилально по другому?


Я же написал, прочитай что такое GIL и как он связан с потоками и native потоков могут работать одновременно и как происходит переключение между потоками (то что regall
кидал например)

Ну и питон как бы интерпретатор… конечно по другому

В чем горе от ума?