Здравствуйте!

Написал я программу на питоне, а она работает в сотни раз медленнее, нежели могла бы. Посему я решил переписать её на С++. Но хотелось бы иметь к ней доступ из питона, ибо, во-первых, переписывать ГУИ совершенно ни к чему, во-вторых, из питона удобнее отлаживать. Посему вопрос - через что организовать интерфейс питон-С++? Я почитал официальное руководство, там, насколько я понял, предлагают каждый раз пересобирать питон (!) с моей библиотекой. А на другом сайте есть статья, в которой характеризуются ажно десять различных методов достижения означенной цели. Очевидно, что я не могу сколько-либо адекватно сделать выбор, ибо являюсь новичком как в питоне, так и в С++. Посему я прошу вас сделать этот выбор за меня.

Грубо говоря, программа-минимум - вызывать из питона функцию, отвечающую за расчёт, и принимать несколько двумерных массивов чисел для отрисовки. Программа-максимум - иметь доступ ко всем моим С++ным функциям и объектам из питона, дабы отлаживать в интерактивном режиме.

Система - линукс (ubuntu), возможно, придётся адаптировать под windows.

Заранее благодарен.

для “с” посмотрите модуль ctypes Для “c++” boost python

Попробуйте Numpy - http://numpy.scipy.org/

doza_and
Для “c++” boost python

Посмотрел, там вроде как надо собирать с помощью build.boost, а я обычный make с грехом пополам асилил. Вопщем, я сделал вывод, что пока я не готов это дело осваивать, лучше всё на голом С++ напишу. Уже сделал подобие графики через ncurses.

alex312
Попробуйте Numpy - http://numpy.scipy.org/

Ежели я ничего не путаю, то я numpy собственно использовал. Матрицы умножает на ура, а во всём остальном совершенно не помогает.

Обедающий философ
в сотни раз медленнее

Обычно бывает 3 ну 5 раз медленнее, иногда вовсе не медленнее чем c++. Если в сотни раз - есть непонимание того что делается
- его надо устранять.

Обедающий философ
я не готов это дело осваивать, лучше всё на голом С++ напишу

c++ посложнее питона будет (намного). Хотя конечно c++ + python наверное сложнее каждой из частей.

Вы конкретнее задачу опишите - может кто что и присоветует. ЕСть много способов ускоритть питон и отлаживать в c++

doza_and
Обычно бывает 3 ну 5 раз медленнее, иногда вовсе не медленнее чем c++. Если в сотни раз - есть непонимание того что делается
- его надо устранять.

Вот я как раз сегодня до сколько-либо работоспособного состояния довёл - получилось в несколько десятков раз быстрее.

doza_and
Вы конкретнее  задачу опишите - может кто что и присоветует.

Ну скажем так, есть прямоугольная сетка, на ней некоторое множество модельных организмов (т. н. агентов). Внутри каждого агента нейронная сеть (собственно в ней и происходит умножение матрицы на вектор, матрица размером около 10*10). И каждый агент может передвигаться из клетки в клетку, общаться с другими агентами, размножаться (попутно мутируя) и умирать. То бишь получается навроде генетического алгоритма (такие вещи ещё называют “искусственной жизнью”, хотя данная конкретная модель не сказать чтобы уж очень живая).

Стало быть, на питоне умножение матриц занимает какую-то пренебрежимо малую часть времени, а основное - это вычисление сигмовидной функции (необходимой для нейронной сети, 10 штук на агента на шаг) и “органов чувств” агента, которые представляют собой банальное копирование (ну в крайнем случае вычисление логарифма). Согласитесь, это смешно. Тогда как на С++, напротив, умножение матриц занимает львиную долю времени. Правда, я ещё не сделал размножение, общение и мутацию, но по идее они отнимают не очень много машинного времени.

Бугага, оказывается, коли сигмовидную функцию определять как 1/(1+exp(-a)), то суммарное время выполнения вырастает в два раза по сравнению с отсутствием сигмы. А ежели её определить как 1/(1+exp(-a*0.001)), то время выполнения почти сравнивается с временем без сигмы. А ежели сигму определять как арктангенс, то ещё лучше. Я так подозреваю, что ей не нравится, что экспонента принимает чересчур большое значение, и что на это значение ещё надо поделить.

Да, думаю Агентов тут надо сажать в c++ вместе с сеткой в которой они живут. В этой задаче в питоновскую часть наверное стоит вынести сбор статистики и расчет функционалов (они ведь наверное нужны?) Они достаточно часто меняются. Кроме того можно туда отправить и графическое отображение состояния. Чистый ctypes будет тут не очень удобен - для работы скорее всего потребуется доступ к классам.
тут swig или boost наиболее частые решения. bjam не очень страшный зверь. Вам нужно только цеплять питон тогда - действуете по инструкции и все изучать премудрости jam не требуется. Освоение будет быстрее чем освоить make. Если будут проблемы спрашивайте.
Питон очень сильно помогает не столько для отладки сколько для анализа результатов - когда надо посмотреть то одно то другое.

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

Непосредственную связку С++ и питона, видимо, всё же изучу попозже, ежели появится необходимость. Спасибо за помощь!

doza_and
можно на С++ статистики в лог писать

Это мы уже двадцать раз проходили. Все зависит от масштаба. Если ваши желания это сделать чтото типа программы wc (word count) на этом можно остановиться.
но если проект более или менее большой - 90% вашего кода будет read write, и я многих таких людей знаю, им просто некогда программить все read-write,read-write…. Судя по вашему описанию - у вас что-то посложнее wc.
Один раз освоив технологию (за 1 день) вы существенно сократите расходы на написание интерфейсов я бы крайне не рекомендовал лениться - потом за это 10 раз заплатите. Связаться с сишным процессом тоже можно см subprocess.Popen, sockets. Тут вы или не получите интерактивности (будете выполнять процесс до конца и не сможете продолжить работу) или вынуждены будете осваивать тонкости синхронизации процессов (думаю дня за 2 легко освоить) Кстати помоему самый простой способ общения со стороны c++ это опять-же освоить boost и использовать библиотеку asio.