Чем асинхронность лучше многопоточности для чат-бота?

Question

[diqueff]

Чем асинхронность лучше многопоточности для чат-бота? И действительно ли лучше?

Во многих туториалах по написанию чат-ботов (в частности рассматривал написание telegram ботов на python) авторы отдают предпочтение именно асинхронности. Также на форумах часто агитируют перейти с потоков на асинхронность и использовать соответствующие библиотеки по типу aiorgam.

Есть ли какие-то проблемы с потоками, или, может, дело в чем-то другом? Хотелось бы услышать конструктивную критику / опровержение

Заранее спасибо!

Comments

[User]

Простота и ресурсы?

[Macaronin]

Это разве не одно и то же?

Answer 1

[mayton2019]

Насчет чят бота не скажу. Вообще скажу.

Если задача связана с вычислением численных метдов например. Или рендерингом 3D. Или крипто-майнингом. Или нейро-сетей - где
CPU -> 100%, I/O -> 0% то тогда тебе прямая дорого в мультипоточность (мультипроцессность). Количество тредов расчитывается обычно по формуле = количество ядер (иногда АЛУ/Threads) умноженное на коєффициентик. Подбирается экспериментально для конфигурации и среды исполнения. У меня для Java-11 выходило что на 4 ядра Core-i3 надо было 5 вычислительных потоков.

Если в задаче главным дирижёром является канал I/O а нагрузка на расчет малаая (парсер) - то используют технологи асинхронизма. Это когда ваши вычисления подписываются на события I/O и 80% времени ничего не делают а только ждут события от I/O. При благоприятных условиях хендлеры могут потреблять вообще 0% ресурсов. Нет событий. Поэтому таких хендлеров можно поднять очень много. Пример - акторные технологии. Хендлер. Актор. Горутина. Пример 10 000 акторов обслуживается 10 потоками исполнителями.

Comments

[mkone112]

мультипоточность (мультипроцессность).

Только мультипроцессность, без мультипоточности.

[Antonio Solo]

Java != Python

Answer 2

[Кирилл Горелов]

Так это вообще то для разных задач придумано.

Условно говоря, многопоточность это когда тебе нужно одну задачу сделать максимально быстро, ты запускаешь потоки.

А асинхронность, это когда тебе нужно не ждать когда сложная задача выполниться, а продолжить выполнение основного действия.

Естественно все это можно смешивать.

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

Comments

[diqueff]

Как раз использовал потоки, чтобы не заставлять ждать пользователя: на каждое взаимодействие с пользователем по потоку
Стоит ли продолжать так делать? Или это костыли?

[Кирилл Горелов]

anijack, я не знаю какую именно вы пытаетесь решить задачу. Возможно там и потоки действительно лучшее решение, чем асинхронность.

[mkone112]

Кирилл Горелов, а так ли уж потоки концептуально отличаются от асинхронности? Как по мне - так разница только в потреблении памяти и неявном переключении контекста.

[Antonio Solo]

mkone112, потоки концептуально отличаются от асинхронности

потому что это совершенно разные модели многозадачности.

[Macaronin]

Antonio Solo, Вот именно, в итоге всё равно получается многозадачность

[mkone112]

Antonio Solo,

потоки концептуально отличаются от асинхронности

чем асинхронные потоки отличаются от асинхронности?

Answer 3

[Владимир Коротенко]

Разницы нет под капотом все тот же thread pool. Важно как вы это все готовите.

Comments

[diqueff]

Не уверен, насколько хорошо мне далась готовка...
Использовал threading + pyTelegramBotAPI, хоть насчет последнего и говорят, что на нем ничего сложнее тестового бота сделать нельзя
А в aiorgam не лез, т.к. с асинхронностью особо не знаком

[Сергей Горностаев]

Неа. Питонячий asyncio крутит цикл событий в одном потоке.

[Владимир Коротенко]

Сергей Горностаев, Не знал таких подробностей. А с чем связано? В принципе потоки на уровне ОС довольно просто реализовать, с учетом того что все языки пишутся на плюсах или с(+-)

[Сергей Горностаев]

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

[Roman K]

Владимир Коротенко, питон далеко не единственный в этом, так что утверждать так уверенно "под капотом все тот же thread pool" — это прям очень опрометчиво. У JS (как у браузера, так и у ноды) есть ивент луп, у го есть шедулер, который в частном случае может быть ивент-лупом (I/O-wait горутины паркуются и ждут события от epoll'ов всяких), у раста так. Да, в общем-то, почти у всех так.

Answer 4

[Antonio Solo]

Какую модель многозадачности - конкурентную (потоки) или кооперативную (асинхронность) лушче применять следует определять для конкретной задачи. С какими библиотеками вы работаете. На сколько хорошо они дружат с потоками или asyncio.

Если ваша программа работает с потоками и нет проблем - так и пусть продолжает работать.