Comments 37
Можете сравнить результаты параллельного питона и реализации на Delphi?
Насколько я понимаю, речь идет о трансформации координат (сомнительно, т.к. не смотря на объем расчетов, задача тривиальна и не требует высоких нагрузок)? Что имели в виду под переносом участка земли? Либо же работа с растрами (тонкопленочный сплайн, аффинные преобразования)?
UFO just landed and posted this here
Извините, но мне кажется это образец быдлокодинга, когда вместо оптимизации алгоритма просто добавляют ещё один компьютер.
И настоящей «паралельности» на самом деле у вас никакой нет. Тот же самый эффект вы получили бы если бы банально запустили 16 копий своей программы, ну только расход памяти на питон-машину был бы поболее и всё.
Вот если бы shared-memory, симафоры и проч проч, это было бы интересно очень.
И настоящей «паралельности» на самом деле у вас никакой нет. Тот же самый эффект вы получили бы если бы банально запустили 16 копий своей программы, ну только расход памяти на питон-машину был бы поболее и всё.
Вот если бы shared-memory, симафоры и проч проч, это было бы интересно очень.
UFO just landed and posted this here
Это образец разных приоритетов — для товарища решить свою задачу на дельфях, для меня — поизучать питон, его оптимизацию и распараллеливание.
Прошу прощение, будучи бывшим геодезистом, у меня в голове не укладывается что есть «перенос объекта с места на место по Земле». Можно конкретизировать, дабы я утешил свое любопытство? :)
UFO just landed and posted this here
Какую СК Земли (UTM/WGS84/etc) используете, если не секрет? Перенос в пределах одной СК? Мне просто интересно, где здесь можно было применить грубую силу.
UFO just landed and posted this here
Если в одной СК, то простые афинные преобразования. Ну в крайнем случае какой-нибудь плином 3ей степени.
gis-lab.info/qa/polynom.html
gis-lab.info/qa/affine-math.html
gis-lab.info/qa/polynom.html
gis-lab.info/qa/affine-math.html
Перенесите в блог про питон.
Я думаю еще стоит написсать чем же это лучше в сравнении с 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.»
А еще лучше написать так и эдак, и сравнить результаты в числах
«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.»
А еще лучше написать так и эдак, и сравнить результаты в числах
Так чем лучше питоновский метод чем треды?
Будет время — обязательно проверю.
Навскидку могу сказать, что PP:
1. создает каждый worker как отдельный python-процесс, т.е. GIL обходится
2. поддерживает запуск на разных серверах, т.е. задача распараллеливается по сети, что уже на порядок интересней
Навскидку могу сказать, что PP:
1. создает каждый worker как отдельный python-процесс, т.е. GIL обходится
2. поддерживает запуск на разных серверах, т.е. задача распараллеливается по сети, что уже на порядок интересней
Различие в числах 136, 133, 137 — скорее всего статистическая ошибка :) Стоило бы провести 5-10 запусков и усреднить результат.
Конечно, ускорение можно получить и на 100 воркерах на 2х ядрах, вот только сравнивать в таком случае нужно не ускоренный вариант с однопоточным, а насколько близко полученное ускорение к идеальному линейному росту. Быть может будет продуктивнее запустить программу 4 раза с разными исходными данными с 4мя воркерами, чем один раз с 16тью ;)
Конечно, ускорение можно получить и на 100 воркерах на 2х ядрах, вот только сравнивать в таком случае нужно не ускоренный вариант с однопоточным, а насколько близко полученное ускорение к идеальному линейному росту. Быть может будет продуктивнее запустить программу 4 раза с разными исходными данными с 4мя воркерами, чем один раз с 16тью ;)
спасибо, надо попробовать веб запросы так параллелить :)
UFO just landed and posted this here
Для научных нужд есть очень хороший модуль pypar — это легкий и простой интерфейс к MPI. С ним распараллеливать простые задачи с циклами — одно удовольствие.
Что касается psyco — то насколько я понимаю, он не работает под 64 бита, так что в реальных случаях его особо не поиспользуешь.
Что касается psyco — то насколько я понимаю, он не работает под 64 бита, так что в реальных случаях его особо не поиспользуешь.
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 кода в Си.
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 кода в Си.
а чем треды не подходят?, интересно посмотреть реализациб через треды питоновские.
Sign up to leave a comment.
Параллельный Питон, начало