Я хочу запустить интенсивную программу cpu в Python через несколько ядер и пытаюсь выяснить, как писать C-расширения для этого. Есть ли примеры кода или учебные пособия по этому вопросу?Как использовать расширения C в python, чтобы обойти GIL
Рассматривали ли вы использование одной из библиотек mpi python, таких как mpi4py? Хотя MPI обычно используется для распространения работы через кластер, он отлично работает на одной многоядерной машине. Недостатком является то, что вам придется реорганизовать свой код для использования коммуникационных вызовов MPI (что может быть легко).
Посмотрите на multiprocessing. Часто игнорируется тот факт, что не глобальное совместное использование данных, а не переполнение загрузок потоков в один процесс - это то, что предпочитают операционные системы.
Если вы по-прежнему настаиваете на том, что ваше интенсивное поведение в ЦП требует потоковой передачи, ознакомьтесь с документацией для working with the GIL in C. Это довольно информативно.
Вы уже можете разбить программу Python на несколько процессов. ОС уже распределит ваши процессы по всем ядрам.
Сделайте это.
python part1.py | python part2.py | python part3.py | ... etc.
ОС будет гарантировать, что часть использует как можно больше ресурсов. Вы можете тривиально передавать информацию по этому трубопроводу, используя cPickle по адресу sys.stdin и sys.stdout.
Без особого труда это может привести к резкому ускорению.
Да - к haterz - возможно построить алгоритм так, чтобы он был подвергнут пыткам, чтобы его не ускорили. Однако это часто дает огромные преимущества для минимальной работы.
И.
Реорганизация для этой цели будет точно соответствует реструктуризации, необходимой для максимизации параллелизма потоков. Так. Начните с параллелизма процессов shared-nothing, пока не сможете доказать, что совместное использование большего количества данных поможет, а затем перейдите к более сложному параллелизму потоков shared-all.
Это хорошее использование расширения C. Ключевое слово, которое вы должны найти, - Py_BEGIN_ALLOW_THREADS.
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
P.S. Я имею в виду, что если вы уже обрабатываете C, например обработку изображений, тогда отпустите блокировку в расширении C, это хорошо. Если ваш код обработки в основном написан на Python, лучше сказать другое предложение для multiprocessing. Обычно не рекомендуется переписывать код в C для фоновой обработки.
многопроцессорное обслуживание легко. если это не достаточно быстро, ваш вопрос сложный.
Самая большая проблема, с которой я столкнулся, пытаясь использовать многопроцессорную и поточную передачу, заключается в том, что при попытке запустить 1000+ потоков (процессов) вы получаете отдельный экземпляр интерпретатора Python с каждым из них. Это становится чрезвычайно дорогостоящим с точки зрения памяти. – Andy
@nalroff: Это звучит не так. Память, используемая для большинства интерпретаторов, используется всеми экземплярами этого интерпретатора. Только разные страницы увеличивают общее использование памяти. Убедитесь, что вы смотрите на правильное значение.Также стоит отметить, что процессы не используют значительно больше памяти, чем дополнительные потоки. –
В каждом случае я использовал многопроцессорный модуль в Python, я всегда видел резкое различие в использовании памяти между процессами и потоками. Во всяком случае, поточный модуль, по-видимому, достаточно быстр для резьбового веб-поиска и тестирования производительности веб-приложения, и это все, что я использую в любом случае. – Andy