Есть ли книга «High Performance Python» на русском?

Question

[Serhiy Romanov]

Подскажите, есть ли перевод книги "High Performance Python. Practical Performant Programming for Humans" By Micha Gorelick, Ian Ozsvald (вот она на сайте издательства) на русский?
Если нет - подскажите подобную литературу, статьи и другое на русском.
Спасибо.

Answer 1

[nirvimel]

Приветствую своих будущих конкурентов (и, возможно, заказчиков). Судя по описанию, сабж (почти каждый пункт в их списке) полностью соответствует моей специализации в последние несколько лет ("Solve large problems while using less RAM" - а на этой теме я вообще "собаку съел").
Но даже по краткому описанию я могу заметить, что книга 2014 уже несколько устарела на сегодняшний день. Например, они упоминают мало кому известный Grasp, но нет совершенно ни слова о такой крутейшей технологии, как Numba, если только она не скрывается под этой фразой: "Use tools to compile Python down to machine code".
И уж как скоро речь идет о performance, то нельзя было проходить мимо темы создания C/C++ расширений. Тем, кто профессионально занимается темой производительности, в любом случае придется столкнуться с этим рано или поздно.

А пока вы ждете перевода, я постараюсь ответить на ваши вопросы по теме.

Comments

[Tsimur_S]

а можно ламерский? сколько в среднем % можно выжать переписав участок кода(пусть будет какой-нибудь machine learning алгоритм) с питона на с++ из предположения что в обоих случаях алгоритм оптимален?

[nirvimel]

Tsimur_S: Есть два случая:
1) Когда скрипт (я специально так называю Python-код, чтобы акцентировать внимание на его интерпретируемой природе) делает в цикле полный проход по данным (пусть это будет numpy-массив). Это наивный подход, приемлем только для прототипирования сложных задач.
2) Когда он выполняет оперирует только векторами (фактически отдает команды на обработку numpy и другим расширениям), не погружаясь в цикл. Это уже профессиональный уровень, должно, быть большая часть той книги посещена именно этому подходу.

Во втором случае при переписывании на C++ в зависимости от "тяжести" вычислений внутри алгоритма выигрыш может достигать от нескольких десятков процентов до нескольких крат (для тривиальных операций, состоящих из одного математического действия, выигрыш, естественно, нулевой). Если это удивляет, то могу объяснить подробно за счет чего это происходит.

В первом случае (с циклом) при переписывании на C++ иногда удается получить выигрыш в 3-4 порядка, то есть в сотни и тысячи раз. Я нисколько не шучу! Интерпретируемый динамически типизированный язык - адски тормознутая штука, в сравнении с SIMD-инструкциями и прочими чудесами оптимизации, которые способен творить современный компилятор C++.

[Tsimur_S]

nirvimel: а за счет чего получается выигрыш во втором случае? собственное расширение будет работать быстрее numpy?

[Serhiy Romanov]

Хорошо, раз материал может быть уже устарелым, тогда поделитесь пожалуйста актуальной информацией по данной теме (можно и на английском).
Я читал про многопоточность, Cython, PyPy, написание расширений на С. Но хочеться до конца разобраться в этих вопросах так как стоит передо мной реальна задача и нужно принимать решение.

[nirvimel]

Tsimur_S: Во-первых, при расчете даже такого простого выражения Y=2*X*X+2*X+2 на каждое арифметическое действие выделяется память под результат этого действия, то есть, если массив X занимал гигабайт, то при расчете этого выражения гигабайт памяти пять раз будет запрошен у ОС и четыре раза освобожден обратно.

Во-вторых, запись результатов вычисления в другую область памяти (вместо вычисления на месте) это крайне неэффективное использование процессорного кеша, доступ к которому может быть в разы (L2) или десятки раз (L1) быстрее чем промах из него и запись в основную RAM.

Но это все мелочи по сравнению с тем, что творит оптимизатор C/C++ над подобными выражениями, вычисляемыми в цикле. Тут включается мощнейшая внутрифункциональная оптимизация, (которая очевидно недоступна в numpy, где каждому математическому действию соответствует отдельная функция), которая достигает того, что на больных объемах данных, например, полином второй степени считается чуть медленнее, чем одно арифметическое действие над тем же аргументом (а при последовательном вычислении полинома второй степени идет пять арифметическое действий).
Но это еще не все. Современные C/C++ компиляторы умеют использовать SIMD расширения современных процессоров, и за счет этого производить действия над 4 или 8 элементами массива одновременно. Numpy, тоже возможно вручную скомпилировать с поддержкой SIMD, но это не даст значительных преимуществ при вычислении сложных выражений (я даже не говорю про алгоритмы) по той причине, что все арифметическое действия выполняются по одному над целым массивом.

[nirvimel]

Serhiy Romanov: PyPy основан на прекрасной идеи двухступенчатой компиляции с применением JIT, и я надеюсь, когда-нибудь он заменит собой CPython, но пока у него остается большая проблема с совместимостью с Numpy (основным инструментом векторных вычислений на Python, на котором завязаны много других необходимых технологий). Проект https://bitbucket.org/pypy/numpy еще слишком сырой и не готов к серьезному применению. По этой досадной причине на данный момент приходится пока отказаться от использования PyPy.

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

[Serhiy Romanov]

nirvimel: Постараюсь описать задачу, которую я решаю. На вход задание поступают ключевые фразы. Для каждой фразы делается запрос в поисковые системы для получение списка сайтов. Для каждого сайта из полученного списка делается парсинг и разбивка на блоки (body, a, readability text). В каждом блоке текста ищутся возможные фразы со списка ключевых слов и их корней.

Сейчас скрипт выполняется линейно. Использую requests, BeautifulSoup 4 для парсинга, pymorphy, ntlk для работы со словами.
Весь поиск сделан с использованием стандартных строковых функций, конструкций типу if item in list и циклов.

Над оптимизацией алгоритма поиска работа видеться регулярно.
Первое что приходит в голову - обрабатывать каждый сайт (получение содержимого, парсинг, поиск фраз) в отдельном потоке (библиотека multiprocessing). Остальные идеи по ускорению хотелось бы получить здесь.

[nirvimel]

Serhiy Romanov: Тут первое, что необходимо сделать, это пустить сетевой ввод/вывод (requests) асинхронно. Для этого существует куча разных вариантов:
1) Использовать asyncio, например, https://stackoverflow.com/a/22414756/5485944 - этот вариант к тому же совместим с threading, то есть можно иметь по несколько короутин внутри каждого потока и по несколько таких потоков на процесс;
2) Использовать gevent, например, https://github.com/kennethreitz/grequests - этот вариант не совместим с threading, поэтому, если вычисления также требуется распараллеливать, то нужно или использовать multiprocessing с симметричными процессами по количеству ядер CPU либо один процесс под чистый ввод/вывод и один многопоточный процесс под вычисления с интерпроцессорными очередями между ними - это довольно экономичный подход в плане потребления памяти, я так часто делаю (с gevent и без него).
3) Использовать threading с большой кучей потоков и синхронным вводом/выводом. Это можно назвать классическим вариантом, самым простым в кодинге, но с известными проблемами: а) высокий расход памяти и потоков ОС; б) если количество ожидающих запросов превысит количество потоков, то CPU останется недонагруженым; в) если ввод/вывод идет слишком быстро, то при большом количестве потоков система окажется перегруженой, вся ОС может начать притормаживать.
4) Вариант (3) с отдельными вычислительными потоками (по количеству ядер CPU) и отдельными потоками ввода/вывода (в безмерном количестве), связанными друг с другом легкими инпроцессорными очередями. Этот вариант решает часть проблем (3).

Это только первое, чего я коснулся - requests. Когда эта задача будет решена, стоит переходить к распараллеливанию вычислительной нагрузки по потокам, там все еще сложнее и интереснее, там начинается борьба с GIL, об этом можно сказать еще стену текста.

[Dimonchik]

по-моему, одна асинхронная работа с сетью + lxml расширит горизонты

[nirvimel]

dimonchik2013: Смотря на сколько требуется расширять горизонты... По сравнению с синхронным I/O в одном потоке - это, конечно, будет прорыв. Но асинхронный I/O + lxml в том же (одном) потоке нагрузит только одно ядро (и упрется в него) на хорошем гигабитном канале при достаточно сложной структуре извлекаемых документов.

[Dimonchik]

согласен - lxml в мультипроцессинг, конечно

[Serhiy Romanov]

nirvimel: Огромное спасибо за ответ.
Расскажите еще про Cython пожалуйста. Что если переписать код на Cython? Или еще критические участки кода на С++? Хотелось бы такой же ответ со ссылками на материалы которые помогут погрузиться глубже в эту тему. Спасибо.

[Николай Карелин]

Вся суть от переписывания кода на Cython или C - в том, чтобы избавится от слишком гибкой типизации нативного Питона (во многих случаях программа на Python медленная не потому, что интерпретатор, а потому, что виртуальная машина должна проверить типы всех операндов, чтобы вызвать нужный C-код). По моему, в задаче Serhiy Romanov большинство типов - строки, и задачка переписывания будет тяжеловатой.

И более актуальный вопрос: а вы мерили, где затык вашей программы - это Python или ожидание из сети или еще что-то? Прежде чем оптимизировать, надо понять, что именно. Если ваша проблема - задержка сети, то тогда надо брать asyncio или multiprocessing.

Answer 2

[Николай Карелин]

По поводу русскоязычных ресурсов: был доклад год назад про внутренности PyObject, здесь https://habrahabr.ru/company/wargaming/blog/263507/ (продолжение вроде здесь pycon.ru/2016/program/content/koshkin - видео есть на YouTube, но я его еще не смотрел), и был мой доклад "Ускорение кода на Python: компиляция и обход GIL", видео и презентация по ссылке здесь https://dev.by/lenta/space-blog/pycon-belarus-2016

Я еще делал продолжение на PiterPy'2016, но видео выступления пока нет и я рассказывал на английском ;)