aiofiles - построен полностью на тредпуле, это не мешает ему быть конкурентным.
aiofile - использует caio под капотом, который для linux использует системные вызовы ядра для асинхронной работы с файлами, или тредпул на си, для мака тредпул на си или реализацию на python тредах для windows.
По поводу баз данных, тоже не правда, sqlalchemy>1.4 тоже не использует никаких тредов если только драйвер не использует их (aiosqlite построен на потоках, иначе никак)
На самом деле никакого параллельного выполнения чего бы то ни было в питоне нет и быть не может. Кто не верит — погулите аббревиатуру GIL.
Это тоже довольно популярное заблуждение, тот-же упомянутый выше caio отпускает GIL когда читает из фалов, ему его держать не нужно, просто отдал в ядро системный вызов и потом как на eventfd тригернется epoll приходи за результатом.
GIL не является проблемой в python, то что вы не можете его выключить для python кода, это правда, если вам нужна, например, математика многотопочная, берите numpy/numba/cython, там или GIL уже отключен при cpu-bound вызовах, или можно его отключить ( "with nogil:" в Cython).
Множество стандартных функций интерпретатора отпускает GIL, та-же работа с файлами, os.pread например, да и вообще поищите в исходниках интерпретатора Py_BEGIN_ALLOW_THREADS все что в теле под этим макросом, выполняется конкурентно безо всякого GIL, и да, sqlite в их числе.
Это не правда. В aiofile использовался posix aio.h там треды появились как раз позже. Ито для совместимости с windows и как более быстрая альтернатива posix aio.h для mac os
Ответ прост, я еще не написал ни caio ни aiofile на тот момент. И если уже докапываться то на windows и MacOS по сути тот-же подход с потоками что и тут. Плюс ко всему сильно зависит от случая, если нужно максимально быстро открыть файл, потом прочитать из него 50 раз из 500 разных мест, то подход с потоками на небольших нагрузках будет быстрее чем aiofile.
А за ссылку спасибо исправлю как только буду за компьютером.
Тут ключевое чтобы это было сделано в CLI интерпретатора, а так работает и в python2 и python3
$ python2
Python 2.7.16 (default, Feb 29 2020, 01:55:37)
[GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 42
>>> b = 42
>>> id(a) == id(b)
True
>>> a = 1234567890
>>> b = 1234567890
>>> id(a) == id(b)
False
$ python3
Python 3.8.2 (v3.8.2:7b3ab5921f, Feb 24 2020, 17:52:18)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a=42
>>> b=42
>>> id(a) == id(b)
True
>>> a = 1234567890
>>> b = 1234567890
>>> id(a) == id(b)
False
>>>
Я предполагаю что все люди разные и для кого-то подача и способ рассказать свою мысль одного лектора, не вызывает желания досматривать. Не рубите весь курс из-за этого, посмотрите по 10-15 минут остальных лекций, мне лично будет приятно.
Все лекции читали и подготавливали совершенно разные люди, никто из них не является профессиональным артистом или оратором со стажем. Зато все прекрасные специалисты, и с удовольствием делятся своим опытом.
Можно и httpx, но он над httpcore, который над h11 (http/1.1) и h2 (http/2), оба на питоне написаны, и перформансом не блещут. В aiohttp и для сервера и для клиента используется написанный на Cython парсер HTTP протокола, и только как фолбек, реализация на python.
Можно померяться бенчмарками, разумеется, но это все выглядит как вкусовщина.
Судя по их примерам там только sqlalchemy.orm, так что для асинхронных библиотек (aiopg/asyncpg) придется самому писать, но благо там не ракеты запускать.
Для Python есть много модулей написанных на C++ (Catboost например) или на Си (numpy например). Расширение для языка можно написать как на C/C++ или кодогенерацией из «псевдоязыка» Cython. Нет ничего удивительного что язык сейчас так популярен. Многие открытые библиотеки написаны таким образом, чтобы всю «тяжелую» работу выполнять в быстром и соптимизированном компилятором коде расширения на С++, который «дергает за ниточки» код на python. Получается, что при правильном применении этого подхода мы не много проигрываем в производительности, но при этом пользуемся всеми плюсами языка со строгой динамической типизацией.
aiofiles
- построен полностью на тредпуле, это не мешает ему быть конкурентным.aiofile - использует caio под капотом, который для linux использует системные вызовы ядра для асинхронной работы с файлами, или тредпул на си, для мака тредпул на си или реализацию на python тредах для windows.
По поводу баз данных, тоже не правда,
sqlalchemy>1.4
тоже не использует никаких тредов если только драйвер не использует их (aiosqlite построен на потоках, иначе никак)Это тоже довольно популярное заблуждение, тот-же упомянутый выше
caio
отпускает GIL когда читает из фалов, ему его держать не нужно, просто отдал в ядро системный вызов и потом как на eventfd тригернется epoll приходи за результатом.GIL не является проблемой в python, то что вы не можете его выключить для python кода, это правда, если вам нужна, например, математика многотопочная, берите numpy/numba/cython, там или GIL уже отключен при cpu-bound вызовах, или можно его отключить ( "with nogil:" в
Cython
).Множество стандартных функций интерпретатора отпускает GIL, та-же работа с файлами, os.pread например, да и вообще поищите в исходниках интерпретатора Py_BEGIN_ALLOW_THREADS все что в теле под этим макросом, выполняется конкурентно безо всякого GIL, и да, sqlite в их числе.
Это не правда. В aiofile использовался posix aio.h там треды появились как раз позже. Ито для совместимости с windows и как более быстрая альтернатива posix aio.h для mac os
Ответ прост, я еще не написал ни caio ни aiofile на тот момент. И если уже докапываться то на windows и MacOS по сути тот-же подход с потоками что и тут. Плюс ко всему сильно зависит от случая, если нужно максимально быстро открыть файл, потом прочитать из него 50 раз из 500 разных мест, то подход с потоками на небольших нагрузках будет быстрее чем aiofile.
А за ссылку спасибо исправлю как только буду за компьютером.
Можно померяться бенчмарками, разумеется, но это все выглядит как вкусовщина.
«Асинхронные библиотеки» по сути же просто очень вкусный «синтаксический сахар» над epoll/kqueue/select.
Сейчас проверим, спасибо.