Есть ли смысл использовать для численных расчетов python?

То есть ты сомневаешься, что на любом языке можно изуродовать код? Про «определение» можно подробнее. Где ты его взял?

почему ты так боишься циклов?

Циклы — громоздкое описание простых операций. В коде с циклами сложнее выявить параллелизм. Зачем надеяться на эвристический векторизатор в компиляторе, когда в векторных и матричных операциях параллелизм явно указан в самой операции?

я его гораздо хуже знаю

Дал прогу на c++ одному

То есть программа на C++ есть, работает, и решается вопрос, писать ли то же на Python? Тогда нет, не стоит.

медленнее плюсов

Возможно - тебе сильно поможет numpy. А возможно - не поможет. Зависит от того, что за числодробление ты делаешь.

В однопотоке вообще он плох ... а вот многопоточность его слабое место.

А хорошее есть что?)

Я тут недавно услышал, что одна фирма для научных расчетов написала код на си + питон как обертка. Причем они расчитывают на кластерах с очень большим количеством данных. Вот я поэтому и призадумался.

Так много кто делает. Ещё раз: https://fenicsproject.org/

FEniCS is a popular computing platform for partial differential equations (PDE). FEniCS enables users to quickly translate scientific models into efficient finite element code. With the high-level Python and C++ interfaces to FEniCS, it is easy to get started, but FEniCS offers also powerful capabilities for more experienced programmers. FEniCS runs on a multitude of platforms ranging from laptops to high-performance clusters.

Но замарачиваться в связке С/С++/... + Python стоит, если у тебя есть вычислительное ядро, которое часто используется.

На плюсах впринципе хватает, т.к. я использую lapack. В основном в задаче у меня все упирается в решение СЛАУ - очень большие матрицы.

Python-обёрток для xLAPACKx и поверх него есть много. Тот же Intel стал распространять MKL со своей сборкой Python. Гугл в реки, и смотри как твои задачи решаются.

Я тут недавно услышал, что одна фирма для научных расчетов написала код на си + питон как обертка

Так делают, когда нужен программный интерфейс для научников. А если нужно просто решить задачу, сомнителен такой подход. Ведь примитивы придется таки делать на plain C, а еще писать обертки к ним. Т.е. основная сложность у тебя упадет в C, и плюсами ты уже не сможешь ее подсластить.

Нафига тебе для расчетов плюсы сдались?

В стандартной библиотеке хороший рандом есть.

Вроде внутри numpy и pandas нативные функции.

Например вот тут зависимость на Lapack, что вообще фортран

http://data.gpo.zugaina.org/gentoo/dev-python/numpy/numpy-1.11.2-r1.ebuild

У Pandas зависимость например на dev-python/bottleneck, что тоже набор нативно реализованых операций.

Остается определить в каких конкретно случаях включается натив.

Зависит от проблемы, очень сильно зависит. Хотя я видел публикации, в которых люди на питоне PDE решали без потери производительности (деталей не помню, быть может использовался Cython). Саму статью не найду, но вот что гугл выдаёт: https://scholar.google.co.uk/scholar?hl=ru&q=python pde&btnG=

http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-o... вот первая из проблем по комбинаторике. там дальше есть задача, где rpython показывает отличные результаты (как по мне).

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

или о молекулярной динамике

не плох* конечно, просто я продолбался немного

при правильном использовании numpy/scipy не надо будет никаких циклов городить для этого.

Как ты предлагаешь решить следующее без циклов?

\sum_i\sum_j\sum_k{a_i a_j a_k f(x(i),y(j),z(k))}

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

квантовый транспорт в полупроводниковых гетероструктурах. (расписывать лень).

с++ на порядки быстрее и точнее питона [при грамотном использовании].

да неужели? Прям точнее? В двух словах, если можно.

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

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

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

В итоге, если все выразить через матформулы и соответственно скормить в scipy, то все чики-пуки.

Как ты предлагаешь решить следующее без циклов?
\sum_i\sum_j\sum_k{a_i a_j a_k f(x(i),y(j),z(k))}

Вот я и говорю: мозг поврежден сишечкой %)

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

Потом делаешь

numpy.einsum('i,j,k,ijk',a,a,a,f);

все. Также рекомендуется к прочтению numpy.tensordot

То есть ты сомневаешься, что на любом языке можно изуродовать код?

Везде можно изуродовать, но где-то это уже сделали за тебя.

Про «определение» можно подробнее. Где ты его взял?

У скриптухи всегда будут какие-то накладные расходы, на то она и скриптуха.

Скорее да чем нет. Если данные нормально влазят в библиотеки типа numpy, то питоновские циклы на PyPy будут достаточно быстрыми.

Могу по яваскриптовому JIT пример привести, чтобы были понятны масштабы в современном мире. На подходящих данных хороший код раза в полтора медленнее сишечки, деоптимизированный медленнее раз в пять. Если дергаешь внешние библиотеки, то самые большие потери - на маршалинге.

У родного питона движок пожиже яваскриптового, но PyPy весьма неплох.

Тебе надо хотя бы какую-то предварительную оценку построить. Если твоя задача считается час, это одно. А если секунду - тогда скорее всего можно не париться на тему скорости.

Обычно, есть два этапа написания кода расчётов:

...

Наконец-то один компетентный комментарий.

Циклы — громоздкое описание простых операций.

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

при правильном использовании numpy/scipy не надо будет никаких циклов городить для этого.

Верно. В целом питон с numpy/scipy и, опиционально, sympy — хорошая альтернатива Matlab/Octave, R, и как более молодой Julia как средствам прототипизации. Позволяют быстро написать и отладить алгоритм, выражаясь «более естественным» образом, нежели на Fortran/C++. Потом, если критична скорость или нужно распараллелить на уровне MPI (при правильном прототипировании shared-memory OpenMP достанется почти даром), пишется код на них (Fortran/C++).

Слабое место питона, как уже отметили — многопоток. Матлаб с Октавой это умеют, питон пока плоховато.

Ты явный вызов циклов заменил косвенным. Конечно, в пхытоне скорость будет выше, т.к. самые тормозные операции будут не в интерпретаторе исполняться, и наверняка там еще какой-нибудь openmp прикручен, а то и CUDA.

А вот в сишечке извращаться смысла нет: цикл можно и явно задать.

А вот в сишечке извращаться смысла нет: цикл можно и явно задать.

Суть не в том, что можно/не можно, а в том, что простыня кода отвлекает от чтения и понимания. Ты видел когда-нибудь 10-кратно вложенный цикл на С? А ведь это не такая уж редкая проблема (суммирование/свертывание) по куче индексов в теории, скажем, углового момента. У самого был проект, где были матричные элементы с 10 индексами (по 5 на кет- и бра-, соответственно). Матричная/тензорная нотация тут indispensable и большинство средств численного прототипирования, вроде Matlab/R/Julia/Numpy их имеют.

Я, например, сейчас сделал проект (и опубликовал в J.\ Phys.\ Chem.\ Lett.) на матлабе, и сразу почти переписал его на... Fortran 2003 для Quantum Espresso. В большинстве мест почти copy/paste (спасибо автоматической аллокации) — добавились декларации переменных и небольшие твики синтаксиса, ну, плюс ко всему, интерфейс к остальному коду. Немногим более 500 строк кода, компактного и читаемого, и заработал он почти сразу. А отлаживай бы я алгоритм сразу в QE...

Ты видел когда-нибудь 10-кратно вложенный цикл на С?

Нет. Но сам писал код с 12-кратной вложенностью. Конечные автоматы — они такие.

Фортраном я, естественно, голову не ломаю. Отлаживаю алгоритмы в тормозной октаве, а уж когда все в порядке, переношу на сишечку: с openMP под CPU и, если алгоритм уж очень тормозной или нужно трассировку, то под GPU — с помощью CUDA. Вот такие бешеные вещи приходится вытворять, чтобы и CPU, и GPU иметь возможность использовать.

Отлаживаю алгоритмы в тормозной октаве, а уж когда все в порядке, переношу на сишечку

Ну вот видишь, сам же такой подход используешь. Как я понимаю, ТС спрашивает именно об этом.

Дык, в октаве/матлабе все легко. И не надо дебильный пхытон учить. И много нужных пакетов есть, а если нет, можно на сишечке написать.

Так что, я категорически против пхытона. Хотя, у него почему-то полно любителей: даже astropy придумали, извращенцы сраные!

А куда без циклов в каких-нибудь приближенных вычислениях?

ТС, бери Си. Это быстро.

И не надо дебильный пхытон учить.

Ой, ну ладно тебе, не более он дебильный, чем JS или Perl. Я вот в последнее время стал на него смотреть — многие из нового поколения используют его как «клей»: например, такие проекты как PySCF, ASE, Horton. Так хорошо бы знать питон, чтобы хотя бы читать их код.

Как я понимаю, питон удобен тем, что позволяет в рамках одного языка и синтаксиса, скажем, считать/распарсить файл по строчкам, полученные данные обработать и, допустим, нарисовать. Без питона пришлось бы связку, скажем, bash/awk/octave/gnuplot делать, что само по себе может и не страшно, но отлаживать куски на 3-4 языках...

не более он дебильный, чем JS или Perl.

Не скажу насчет перла, но жабоскрипт — просто идеальный ЯП, если с пхытоном сравнивать. На жабоскрипте мне нет труда накалякать код для веб-странички. А на пхытоне я две недели когда-то писал элементарную генерилку изображений линз для фрикада.

Кстати, из-за того, что во фрикаде без пхытона вообще невозможно работать, я на Компас-3D перекочевал. И хрен с ним, что пиратский на пиратской же мастдайке в виртуалбоксе. Зато работает!

Рисовать графики, кстати, на mathGL можно. Ну, а для обработки одноразовых данных связка octave + gnuplot отлично отрабатывает.

А куда без циклов в каких-нибудь приближенных вычислениях?

Никуда. Только явно их выписывать не надо. Это слишком низкий уровень для таких вычислений. Все равно что на асме писать.

ТС, бери Си. Это быстро.

лучше один раз научиться писать «векторный» код, чем продолжать дрочить циклы в С. А потом (если еще желание останется) можно будет продолжить писать на том же Си, только на совершенно другом уровне.

Причем я практически полностью уверен в том, что код на С-шечке, который напишет ТС (да и большинство здесь присутствующих) окажется медленнее кода на питоне с использованием numpy

окажется медленнее кода на питоне с использованием numpy

Читер, не каждый тут сумеет BLAS с LAPACK-ом на коленке налабать :))

окажется медленнее кода на питоне с использованием numpy

Это невозможно. Особенно если сишный код использует CUDA ☺

окажется медленнее кода на питоне с использованием numpy

Это невозможно. Особенно если сишный код использует CUDA ☺

слишком много если :)

Да даже с тем же лапаком и бласом из GSL сишный код не может уступать пхытону.

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

Да даже с тем же лапаком и бласом из GSL сишный код не может уступать пхытону.

Эти все лапаки, бласы и прочие надо еще вкрутить. Из орущих тут «питон тормоз, С рулит» никто бы этого не делал. Потому что тот, кто это бы делал знает, что пистон с numpy будет работать на том же движке и в итоге скорость будет сопоставимой.

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

возможно в твоем конкретном случае это так и есть.

Интересное решение. Мне еще как раз интегрирование квадратурами Гаусса нужна была, а она уже готовая есть))

В основном у меня был затык по скорости при вычислении тройного интеграла и решении слау. А слау реализована в numpy, что примерно одного уровня с lapack. Поэтому по скорости вроде не так страшно.

Теперь осталось разобраться смогу ли я на питоне управление переписать.

З.ы. почему стал интересоваться питоном - на сишке код слишком сложным для понимания стал.

Интересное решение. Мне еще как раз интегрирование квадратурами Гаусса нужна была, а она уже готовая есть))

о чем и речь. Все реализовано уже так, что по сути можно при программировании формулами писать. Главное «забыть» о низкоуровневом мышлении.

В основном у меня был затык по скорости при вычислении тройного интеграла и решении слау. А слау реализована в numpy, что примерно одного уровня с lapack. Поэтому по скорости вроде не так страшно.

Теперь осталось разобраться смогу ли я на питоне управление переписать.

управление?

З.ы. почему стал интересоваться питоном - на сишке код слишком сложным для понимания стал.

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

управление?

Основные классы, логика программы итд

есть вариант, что это все на пистоне можно будет проще и компактней реализовать.

Все реализовано уже так

Вот, вот. Я тут решил проверить сколько будут перемножаться матрицы 1000 на 1000. На C++, Fortran (оба варианта собраны с флагами "-march=native -Ofast") перемножение посредством циклов, с предварительным транспонированием одной матрицы для ускорения, заняло ~1 сек; без транспонирования ~4.5 сек; а встроенной в Fortran функцией matmul - 1.2 сек. На Python с циклами 7-8 минут, а с использованием numpy.matmul всего 0.3 секунды.

Zodd, для линейной алгебры numpy использует код, основанный на коде библиотеки LAPACK, так что считать тоже шустро должно.

А можешь привести наивный код на плюсах? А то я решил на С протестить, так походу компилятор шутки шутить изволит.

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

Да. Но где-то это сделать намного проще.

Именно, поэтому люди использующие Python для расчетов (нет они не сумашедшие), по крайней мере, если оно считается не сутками/неделями, используют библиотеки numpy+scipy, которые написаны на C и работают очень шустро.

До дома доберусь, приведу. Там просто 3 вложенных цикла, двумерные массивы статические.

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

С++ (g++_4.8.4 -march=native -Ofast):

#include <iostream>
#include <cstdlib>
#include <cstdio>
#include <ctime>
 
using namespace std;
 
const int n=1000;
double a[n][n], b[n][n], bt[n][n], c[n][n];
 
int main()
{
	for (int i=0; i<n; i++)
	  for (int j=0; j<n; j++) {
	    a[i][j] = (rand() % 100)/100.0+1.0;
	    b[i][j] = (rand() % 100)/100.0+1.0;
	  }
    
	for (int i=0; i<n; i++)
	  for (int j=0; j<n; j++) {
            bt[i][j] = b[j][i];
	  }
 
  clock_t start;
  start = clock();
 
	for (int i=0; i<n; i++)
	  for (int j=0; j<n; j++) {
            double cc = 0;
  	    for (int k=0; k<n; k++)
                cc += a[i][k]*bt[j][k];
	    c[i][j] = cc;
	  }
 
	cout<<(clock()-start)/(double) CLOCKS_PER_SEC<<endl;
	return 0;
}

Python3:

import random
import time
import numpy as np

n = 1000

AA = [[random.uniform(0, 1.1) for x in range(n)] for y in range(n)]
BB = [[random.uniform(0, 1.1) for x in range(n)] for y in range(n)]

DD = np.empty([n,n], dtype=np.float64)

start_time = time.time()

DD = np.matmul(AA, BB)

print(" Time %s seconds :" % (time.time() - start_time ))

На фортране примерно то же самое, что на C++

Всё зависит от того что ты считаешь и сколько раз тебе придется считать с другими данными. А может ты вообще на GPU считать собрался.