Параллельный Питон, начало

[@naum]

Можете сравнить результаты параллельного питона и реализации на Delphi?

[@vhbit]

Постараемся в скором времени — у меня мак, у товарища виндовс, надо будет поставить ему питон и прогнать тесты.

[@naum]

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

[@ivlis]

Извините, но мне кажется это образец быдлокодинга, когда вместо оптимизации алгоритма просто добавляют ещё один компьютер.

И настоящей «паралельности» на самом деле у вас никакой нет. Тот же самый эффект вы получили бы если бы банально запустили 16 копий своей программы, ну только расход памяти на питон-машину был бы поболее и всё.

Вот если бы shared-memory, симафоры и проч проч, это было бы интересно очень.

[@vhbit]

Это образец разных приоритетов — для товарища решить свою задачу на дельфях, для меня — поизучать питон, его оптимизацию и распараллеливание.

[@ivlis]

А мне казалось приоритет это ускорить выполнение программы…

[@ivlis]

Тогда чем не устраивал прога на дельфях, если один раз нужно?

[@vhbit]

Не устраивала не программа, а незнание питона :)

[@vhbit]

Правильно, ускорить, но с доп. условием — в пределах изучения питона, а не алгоритма.
Дисклеймер же не зря писался:

мне же захотелось попробовать в действии питон, в коем я спецом не являюсь

;)

[@naum]

Прошу прощение, будучи бывшим геодезистом, у меня в голове не укладывается что есть «перенос объекта с места на место по Земле». Можно конкретизировать, дабы я утешил свое любопытство? :)

[@naum]

Какую СК Земли (UTM/WGS84/etc) используете, если не секрет? Перенос в пределах одной СК? Мне просто интересно, где здесь можно было применить грубую силу.

[@Indalo]

Если в одной СК, то простые афинные преобразования. Ну в крайнем случае какой-нибудь плином 3ей степени.

gis-lab.info/qa/polynom.html
gis-lab.info/qa/affine-math.html

[@naum]

Вот это меня и смутило! СК WGS84.

[@KF_NEXUS]

Перенесите в блог про питон.

[@vhbit]

Готово

[@Imposeren]

Я думаю еще стоит написсать чем же это лучше в сравнении с threads:
«The most simple and common way to write parallel applications for SMP computers is to use threads. Although, it appears that if the application is computation-bound using 'thread' or 'threading' python modules will not allow to run python byte-code in parallel. The reason is that python interpreter uses GIL (Global Interpreter Lock) for internal bookkeeping. This lock allows to execute only one python byte-code instruction at a time even on an SMP computer.»

А еще лучше написать так и эдак, и сравнить результаты в числах

[@ivlis]

Так чем лучше питоновский метод чем треды?

[@Imposeren]

threading.Thread и PP — оба матода «питоновские»
причемthreading есть на docs.python.org.

Если верить документации про PP, то он на самом деле более параллелен, т.к. threads «страдают» от того, что обычно в Python нельзя запускать несколько байткодов параллельно, а в PP это как-то обошли

[@ivlis]

Ну треды это вещь языко-независимая. Я так понимаю PP это костыль, который запускает ещё один интерпретатор?

Я пытаюсь понять, питон для мульттрединга это гуд или нет.

[@vhbit]

Будет время — обязательно проверю.

Навскидку могу сказать, что PP:
1. создает каждый worker как отдельный python-процесс, т.е. GIL обходится
2. поддерживает запуск на разных серверах, т.е. задача распараллеливается по сети, что уже на порядок интересней

[@Sannis]

Различие в числах 136, 133, 137 — скорее всего статистическая ошибка :) Стоило бы провести 5-10 запусков и усреднить результат.

Конечно, ускорение можно получить и на 100 воркерах на 2х ядрах, вот только сравнивать в таком случае нужно не ускоренный вариант с однопоточным, а насколько близко полученное ускорение к идеальному линейному росту. Быть может будет продуктивнее запустить программу 4 раза с разными исходными данными с 4мя воркерами, чем один раз с 16тью ;)

[@Joka]

спасибо, надо попробовать веб запросы так параллелить :)

[@Valery35]

ddos-им AmazonS3? :)

[@vhbit]

Не лучший вариант.

[@Joka]

а как же чувство любопытства и извечный вопрос — а что будет если… ?:))

[@yoihj]

«Параллелить» веб-запросы лучше всего асинхронностью.
pycurl спасет, гуглить «pycurl.CurlMulti»

[@vhbit]

Да, можно создавать прямые имена, но sin, cos и т.д. используются в разных функциях, поэтому при выполнении в PP пришлось бы создавать такие имена в каждой. Поэтому закинуть единожды в __builtins__ показалось проще и быстрее.

[@math]

Для научных нужд есть очень хороший модуль pypar — это легкий и простой интерфейс к MPI. С ним распараллеливать простые задачи с циклами — одно удовольствие.
Что касается psyco — то насколько я понимаю, он не работает под 64 бита, так что в реальных случаях его особо не поиспользуешь.

[@yoihj]

1. самое простое, как уже сказали выше — просто запустить 2 процесса и дать им разные части задачи (учитывая, что у вас никакой синхронизации в проекте не было) и не геммороиться с распараллеливанием

2. multiprocessing (стандартный модуль c 2.6)

from multiprocessing import Process
p = Process(target=f, args=('bob',))
p.start()
p.join()

3. решение sin/cos и т.п. лежит в cython+gcc(mingw32 под винду) (cython — модуль, гуглить при необходимости: «cython sin») — избавляет от dictionary lookup'ов для названий функций за счет компиляции слегка модифицированного Python кода в Си.

[@AlienZzzz]

а чем треды не подходят?, интересно посмотреть реализациб через треды питоновские.