LINUX.ORG.RU

Оптимизация вычисления большой матрицы расстояний

 


0

3

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

Сейчас используется следующий код:

distance_matrix = np.ndarray((len(foo),len(foo)))
for i, bar1 in enumerate(foo):
    for j, bar2 in enumerate(foo[i+1:]):
        distance_matrix[i,j] = hight_level_python_function(bar1, bar2)

И работает он очень долго, даже если разбивать матрицу на несколько, и считать каждую в отдельном процессе. На низкоуровневых языках переписать метрику необоснованно трудозатратно. Кеш на hight_level_python_function уже есть.

Как быть?



Последнее исправление: helium (всего исправлений: 2)

На С не подходит ?

anonymous
()

Мне говорили матрицы на видеокарте складывать хорошо, можно таски прямо из пидона генерить.

anonymous
()
Ответ на: комментарий от helium

Зная что она делает и что принимает вполне возможно.

Cactus64k
()
Ответ на: комментарий от helium

Хм. Не знаю, что у тебя там за конкретика, но самым тупым способом было бы считать на GPU.

Solace ★★
()

Еще вариант: использовать Cython. Тебе надо в основном расставить метки статических типов, особо не меняя остального, и ты можешь получить значительный прирост производительности прямо сразу. Тебе даже не требуется отмечать статические типы для всех переменных, а только там, где нужна производительность.

Например, разница по скорости прогонки без и с cython (просто со статическими типами) составляет примерно 10 раз. Вместе с чтением манов это потребовало минут 20-30.

На GPU я бы считал, только если на CPU никак не затащить: в зависимости от реализации и алгоритма high_level_python_function может дерьмово адаптироваться под видеокарты (я про условные переходы и прочую подобную радость).

lu4nik ★★★
()

https://habrahabr.ru/post/167503/

вот толковый пост, я им пользовался, пока не понял, что на сях существенно быстрее. и я бы попробовал сравнить производительность хотя бы для упрощённого варианта метрики.

ZERG ★★★★★
()

Никак. Когда ты выбрал питон для вычислительной задачи, ты уже создал себе проблему. Для этого есть фортран

hotpil ★★★★
()
Ответ на: комментарий от Int64

Просто покупайте amd или карты специально предназначенные для рассчётов. Ну это на случай если двойная точность чисел с плавающей точкой действительно нужна. На обычных нвидиях производительность таких вычислений искусственно ограничена.

anonymous
()
Ответ на: комментарий от four_str_sam

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

Int64 ★★★
()
Ответ на: комментарий от anonymous

Ну на специализированных видеокартах думаю да, с этим проблем не должно быть.

Int64 ★★★
()
Ответ на: комментарий от ZERG

Не ну если какой-нибудь текст разбирать, может быть. Но для данной конкретной задачи, где нужно матрицу крутить, питон заведомо обречен.

hotpil ★★★★
()
Ответ на: комментарий от hotpil

Читай выше, у меня метрика на строках.

helium
() автор топика

Что за метрика то?

psv1967 ★★★★★
()

Как быть? Варианта три:

1. Купить кучу железа и ускорить вариант «считать каждую в отдельном процессе»

2. Поувольнять криворуких разрабов которые не могут переписать критичный кусок хотя бы на cython

3. Забить

Из простых вариантов решения по п.1 - ipython parallel.

ei-grad ★★★★★
()
Ответ на: комментарий от ei-grad

Ещё вариант - в зависимости от задачи, возможно метрика между всеми парами элементов и не нужна... ну как минимум точное значение не нужно.

ei-grad ★★★★★
()
Последнее исправление: ei-grad (всего исправлений: 1)
Ответ на: комментарий от anonymous

Не искусственно, а специально. В играх оно не нужно и потому невыгодно и отъедало бы транзисторный бюджет у нужных в играх fp32 блоков.

anonymous
()

Можно попробовать
itertools.power
itertools.starmap

А вообще правильно советуют насчет GPU.
Ещё можно считать на кластере Spark/Hadoop
или scipy.spatial.distance.pdist, если метрика подойдет

Bell
()

перепиши этот код на java работать станет раз в 10(минимум) быстрее (не шучу)

почему на java-на него проще всего и все что есть в питоне есть в джаве(в смысле синтаксиса и функционала)

да говорю как работавший с большими сервисами на питоне и переписывавши

jsi36331
()
Ответ на: комментарий от jsi36331

...и переписывавший все на джава

работать начинала просто реактивно

питон нереальный тормоз

jsi36331
()
Ответ на: комментарий от ZERG

на сях существенно быстрее. и я бы попробовал сравнить производительность хотя бы для упрощённого варианта метрики.

(если после этого моего поста опять вылезут верущие питонисты вброшу линк,щас лень искать)

есть тесты сравнения скорости питона с другими языками/фреймпорками

питон выигрывает иногда у javascript компиляторов

С++ в 100(сто) и более раз быстрее на всех тестах-включая архивирование и длинные рекурсии/деревья

java всего в 80 раз быстрее питона

jsi36331
()
Ответ на: комментарий от jsi36331

С++ в 100(сто) и более раз быстрее

java всего в 80 раз быстрее

Ты всё время чего-то не договариваешь. Чего-то важного, вроде «быстрее чистого Питона на чисто вычислительных задачах».

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

поэтому я и написал

станет раз в 10(минимум) быстрее (не шучу)

ибо чтение данных/коннект к БД одинаково медленный,но вот время обработки логики внутри питона и джавы-даст большой реальный выигрышь в производительности

jsi36331
()
Ответ на: комментарий от jsi36331

Что такое «скорости питона», когда либы для сложных вычислений типа numpy и так реализованы через фортрановские и сишные библиотеки? Никакого выигрыша ты там не получишь, один проигрыш

Bell
()
Ответ на: комментарий от jsi36331

но вот время обработки логики внутри питона и джавы-даст большой реальный выигрышь в производительности

Это опять сказки, что Ява быстрее оптимизированного Си, или ты реально встретил вычислительные программы на чистом Питоне?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

или ты реально встретил вычислительные программы на чистом Питоне?

я встретил обычные вебсервера на питоне которые лагали тормозили текли и зависали

и банально портировав код 1 в 1 без каких либо изменений на java-пофиксило все проблемы

и кто сказал что ява быстрее си когда я говорю что ява всего в десятки раз ббыстрее питона

...

jsi36331
()
Ответ на: комментарий от jsi36331

Казалось бы, какое отношение военные истории о веб-серверах имеют к вопросу о вычислении матрицы, но ТНБ с тобой.

tailgunner ★★★★★
()
Ответ на: комментарий от jsi36331

Вбрасывай, я один из таких :)

http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-o...

вот совершенно безумная серия тредов про оптимизацию задачи.

http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codin...

особенно вот этот, где предложенный алгоритм на С уступает варианту на Rpython.

ZERG ★★★★★
()
Ответ на: комментарий от tailgunner

Это не чистый Python: RPython is a restricted subset of the Python language. It is used for implementing dynamic language interpreters within the PyPy toolchain. Но в данном случае это не имеет значения. А если уж нужен чистый, то в том же посте Python 3.3 всё равно хорошо управляется.

ZERG ★★★★★
()
Ответ на: комментарий от tailgunner

Это опять сказки, что Ява быстрее оптимизированного Си, или ты реально встретил вычислительные программы на чистом Питоне?

зачем тогда нужен Си? Пусть каждый купить себе по 16гб озу и будет иметь супер-пупер перформанс

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

зачем тогда нужен Си? Пусть каждый купить себе по 16гб озу и будет иметь супер-пупер перформанс

Большинство научных расчетов так сейчас и делается на питоне (через сишные, фортрановские библиотеки и GPU). А Си и не задумывался языком для производительных вычислений, для этого всегда был фортран, Си ему проигрывает.

Bell
()

И работает он очень долго, даже если разбивать матрицу на несколько

Дели мельче. Так, чтобы размер не превышал хотя-бы 1000. И замеряй производительность. Пайтон очень тупит на простых структурах данных больших размеров, причём даже при наличии ресурсов. В особенности это касается словарей. Вот только не уверен, насколько серьёзно это касается остальных типов данных.

blexey ★★★★★
()
Ответ на: комментарий от Bell

Есть сравнения? У меня в лабе все пишут на сях (не слышал про людей, которые на фортране гоняют расчёты).

ZERG ★★★★★
()
Ответ на: комментарий от Bell

Я про тот момент, где С проигрывает фортрану. Если есть источник, где подробно это обсуждается, я бы с удовольствием почитал.

ZERG ★★★★★
()
Ответ на: комментарий от ZERG

Да, массив 1000х1000 (double) самое оно, попытки сделать больше выжирают всю доступную память.

Прверил сейчас

N=50000; d=np.ones((N,N), dtype='float32')

забирает 8.96 GB как и должен

Bell
()
Ответ на: комментарий от Bell

Хм, тогда быть может дело в специфике моего алгоритма. Создать-то один такой я тоже могу, а вот работать с подобными здоровыми матрицами - проблематично, особенно, когда у тебя хранятся данные за несколько шагов. Я понимаю, что подобные вещи лучше считать на кластере, но тестировать тоже где-то нужно.

ZERG ★★★★★
()
Ответ на: комментарий от ZERG

Я про тот момент, где С проигрывает фортрану. Если есть источник, где подробно это обсуждается, я бы с удовольствием почитал.

У меня нет источника, я просто знаю, что многие вычислительные библиотеки написаны на фортране. Может дело не в языке, а в том, что фортрановским кодом больше занимались. Но это неудивительно, язык
создавался для расчетов, в отличие от Си.

Bell
()
Ответ на: комментарий от Bell

Си и не задумывался языком для производительных вычислений

он задумывался просто низкоуровневым языком. Таким вот кроспплатформенным ассемблером

для этого всегда был фортран, Си ему проигрывает

в наше время это уже сказка если чё

reprimand ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.