Comments 20
Ну... Тогда, наверное, есть и перпендикулярное программирование? Может все-таки это разбивка на потоки, которые выполняются одновременно.... Может быть, если ядер много.. Или квазиодновременно, если их не достает...
И вопрос: при реальном исполнении потоков на разных ядрах (или разных процах) вы уверены, что
но в простых случаях лучше использовать
shared memory
вообще будет доступно на другом проце/ядре.
Параллельное программирование есть и успешно (или неуспешно) используется в мире.
Просто в данном конкретном случае имелось ввиду "праллельные вычисления", или распределенные вычисления? Я бы на месте автора перефразировал вступительный абзац. Даже ссылка ведет на "параллельные вычисления"
Ссылка, действительно не очень соответствует. Я использовала кальку с английского . Все же тут речь именно о методе построения алгоритмов и написания программ, а не о конкретных вычислениях. То есть я имела в виду программирование как навык.
Не надо использовать кальку с английского, особенно в том случае, если в результате получившееся выражение уже имеет в языке иное и давно устоявшийся смысл. "Параллельное программирование" это методика программирования, а не то, о чем вы пишете всю статью.
То есть я имела в виду программирование как навык.
Так под параллельным программированием часто подразумевают парное программирование, поэтому построение алгоритмов, которые можно горизонтально распределить. Это не обязательно вычисление в несколько потоков ядра, это именно архитектура алгоритмов, которая позволяет вычислять что-то несколькими участниками, то есть "Распределенные вычисления".
Parallel Computing это взгляд со стороны теории как на вычислительную проблему.
Parallel Programming - со стороны возможностей, предоставляемых Execution Model для вашего языка или фреймворка и конкретным Runtime.
Разница между ними как между правилами дорожного движения и инструкцией по управлению автомобилем.
Distributed Computing - вычислениями в абстрактных распределенных средах (distributed systems), где несколько компьютеров соединены сетью.
Shared memory используется именно для процессов (processes), так как у них нет общего доступа к памяти, в отличие потоков (threads). Код Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код. Shared memory работает в любом случае. В документации это описано.
Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код
Возможно вы имели какой-то конкретный случай, а так есть os.sched_setaffinity .
Можете привести примеры приложений где это стоит использовать на практике, а в каких случаях лучше поискать другие альтернативы?
В моей практике я сталкивалась в основном со случаями, когда и это не годится из-за не-pickable начинки объектов, и тогда приходилось строить решение с помощью событий и других средств.
Мне в голову первым делом приходит ситуация, когда какие-то изменения в объект вносятся через интерфейс, который живет в своем процессе, а сам объект используется для вычислений в другом процессе. Например, вы настроили 3Д модельку чайника на газовой горелке, потом для нее другой процесс рассчитал распределение тепла и вернул эти данные в окно визуализации.
Здесь с одной стороны удобно передавать массивы данных, они скорее всего pickable (однако зависит от класса модели), а с другой стороны, при достаточно высокой детализации копировать обновленные данные туда-сюда между процессами очень накладно. Эффективнее один раз передать (это медленно), а потом уже SyncManager будет передавать только изменения, что гораздо быстрее.
Но мне кажется, это всегда некоторый компромисс)
Ещё приходит на ум вариант передавать данные через unix-socket или tcp-socket.
Безусловно, есть тьма более низкоуровневых решений, которые вероятнее всего при должной реализации будут более эффективны. Но прелесть Python multiprocessing как раз в высоком уровне абстракции.
прокачивать данные через socket должно быть заметно медленнее, чем передача через общую память.
Общей памяти может физически не быть.
А так вообще для таких вещей в природе существует MPI.
Не понял, что значит "может физически не быть". Интерфейс к общей (разделяемой) памяти - часть стандартной библиотеки Python:
https://docs.python.org/3/library/multiprocessing.shared_memory.html
Ну а вслуче, когда на системе закончилась память, наступает пора поиска новых решений на замену тех, что приводят к истощению ресурсов машины.
А алгоритм может быть так построен, что не так уж много данных нужно передавать, или эта часть не является бутылочным горлышком
Спасибо! Решение, которое вы предложили для меня сработало)
Python Multiprocessing. Обмен данными между процессами. Передача объектов пользовательских классов