NumPy не встает :(

[perasperaadastra]

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

[Физик-Лирик]

Уравнение Пуассона - это образно, оно (для электрического поля) было первым в фундаментальной системе уравнений полупроводника, были ещё уравнения непрерывности для дырок и электронов, диффузия и дрейф для плотности токов , генерация-рекомбинация, распределение легирования и прочее. До К.У.Б в чистом виде редко доходили, скорее использовали его выводы, типа проводимостей или распределения носителей. Впрочем, я там стоял рядом, "не знал, не знал, и забыл". Просто в основном использовались методы конечных элементов (иногда конечных разностей), методы частиц (ну да, типа Монте Карло) выглядили иногда интересно и свежо.

Да, такие системы уравнений были стандартом (интересно, как сейчас дела обстоят). Как я уже упоминал, одна из проблем такого подхода - все коэффициенты (диффузии, подвижности) были в лучшем случае функциями поля. Это верно только в случае равновесной плазмы. Однако, на п-н переходах или в катодной области газоразрядной плазмы (тоже моделировали) градиент поля большой (скачок потенциала), и функция распределения не будет уже равновесной. А посему коэффициенты уже формально не будут работать. Интересно, сейчас тоже диффуры решают или же моделируют частицы (раньше, понятное дело, это было затруднительно в силу слабости компьютеров).

[Физик-Лирик]

Пераспераадастра, мне кажется, что в Вашей постановке доля NumPy в общем объёме вычислений мала, поэтому его влияние на конечную скорость тоже незначительно, каким бы быстрым NumPy сам по себе не был, а суммарная производительность определяется скорее чистым Питоном, который совсем не шустрый. Есть варианты более быстрого PyPy, но я не пробовал, не знаю как он дружит с NumPy.

А может имеет смысл переписать на Спарке/ Питоне, чтобы распараллелить? Я, правда, не знаю, как это сделать.

[flip_flop]

Меня продолжают терзать смутные сомнения, что нумпай используется как то не так. Вот, кстати, классика жанра на тему ускорения удава. Не для новичков, но всё-таки.

[flip_flop]

[ Однако, на п-н переходах или в катодной области газоразрядной плазмы (тоже моделировали) градиент поля большой (скачок потенциала), и функция распределения не будет уже равновесной. А посему коэффициенты уже формально не будут работать. Интересно, сейчас тоже диффуры решают или же моделируют частицы (раньше, понятное дело, это было затруднительно в силу слабости компьютеров).

В нашем случая реальный p-n переход был не резким а плавным, что обосновывало применение диффуров как аппроксимации. А так, да, согласен, формально математическое представление физики всегда имеет ограничения, если копать вглубь. Даже для подхода метода частиц

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

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

[perasperaadastra]

А может имеет смысл переписать на Спарке/ Питоне, чтобы распараллелить? Я, правда, не знаю, как это сделать.

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

[flip_flop]

Моё имхо - не применяйте Питон для численных методов. Он хорош как обёртка (wrapper) над С/Cython, тот же NumPy весьма хорош (там, где он имеет область преимущественного применения), Matplotlib, Panda. Хорош и как универсальный язык для охвата многих вещей. Но не для численных методов (сам по себе). Но в нём легко вызывать функции, имплементированные на том же С, там. где это надо. Посмотрите указанную раннее ссылку ускорения удава .

[perasperaadastra]

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

PS

Я добавил собственный класс 2д векторов, и время выполнения сократилось на 40%.

[flip_flop]

Вам надо создать матрицу большого размера (size,dim), где size - число частиц, dim - размерность (2 или 3) и работать сразу с большими матрицами/векторами используя подход, называемый векторизацией. Классика жанра - что для Матлаба, что для НумПая.

Я для любопытства установил PyParticles и у меня в 3D картинке фонтан с 250К частиц живенько так фонтанирует. Посмотрите как люди используют стандартный набор инструментов - NumPy, SciPy, PyOpenGL, Matplotlib, PyOpenCL. К Ситону я бы приступал только после детального изучения NumPy и всех его сильных сторон.

[perasperaadastra]

И все таки нампай меня разочаровывает. Я решил попробовать отдать ему как можно большую часть вычислений. Для этого я избавился от классов и сделал единую матрицу частиц в формате [позиция х, позиция у, скорость х, скорость у]. Я временно убрал обработку столкновений между частицами и оставил только проверку.

Code: Select all

while t<10:
    z = 0
    # check for collisions between particles
    for i in range(0,quantity):
        for k in particle[(i+1):quantity,:]:
            if np.sum(np.square(np.subtract(np.add(particle[i,0:2], particle[i,2:4]), np.add(k[0:2], k[2:4])))) < radsq:
                z += 1

    for i in particle:
        # check for collisions with borders
        if (np.sum(i[0:3:2]) > width) or (np.sum(i[0:3:2]) < 0):
            i[2] = -i[2]
            
        if (np.sum(i[1:4:2]) > height) or (np.sum(i[1:4:2]) < 0):
            i[3] = -i[3]
 
    # move
    particle[:,0] += particle [:,2]
    particle[:,1] += particle [:,3]

    print(z)
    
    t += 1

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

Code: Select all

    for i in range(0,quantity):
        for k in particle[(i+1):quantity,:]:
            if np.sum(np.square(np.subtract(np.add(particle[i,0:2], particle[i,2:4]), np.add(k[0:2], k[2:4])))) < radsq:
                z += 1

ИМХО, таких средств, чтобы без циклов и прочего просчитать попарные столкновения, в нампае нет (или есть, но спрятаны так хорошо, что мне не найти). Так что, думаю, Ситону нет альтернативы. Если бы он еще вставал нормально через pip3.

[flip_flop]

Вам надо научиться работать с большими матрицами (векторами) вместо массивной работы внутри циклов с элементами матрицы (маленькой размерности, N=3), в последнем случае нумпай не имеет смысла. Посмотрите как это сделано в PyParticles, они используют NumPy и у них всё работает быстро.

[perasperaadastra]

Многоразмерные матрицы это для меня слишком сложно. А вот Ситон вполне интуитивен. Я только что переписал ботлнековую в Ситоне, и время обработки 10 кадров сократилось с 3.8 секунд до 0.09. Сейчас я остальные функции туда же отправлю, и код оживет.

[flip_flop]

Ну, один аспект Вы освоили. Но, всё таки, надо овладевать основами численных методов с производительными библиотеками, в частности, с НумПаем. Sorry, я имел в виду не размерность массивов (хотя NumPy позволяет работать с Nd массивами, типа А(k_1,k_2,k_3,,,,k_Nd) ) а размер матрицы (котарая по определению двумерная): Nd=2, A=(n,m), n=1,...,N; m=1,...,M; где N и M достаточно большие, N>>3, M>>3

И почитайте про векторизацию.
Using NumPy arrays enables you to express many kinds of data processing tasks as concise array expressions that might otherwise require writing loops. This practice of replacing explicit loops with array expressions is commonly referred to as vectorization. In general, vectorized array operations will often be one or two (or more) orders of magnitude faster than their pure Python equivalents, with the biggest impact in any kind of numerical computations.

Другими словами, циклы убивают скорость.

Ну и там, где нельзя обойтись без циклов (иногда и такое бывает), можно тяжёлые вещи писать на чистом C а потом вызывать C-шные функции через ABI. Вообщем, наука умеет много гитик. Но всё сводится к векторам и матрицам, так что начинать надо было бы с НумПая

[perasperaadastra]

В большинстве задач нампай, наверно, незаменим, но в данном случае, имхо, нет ничего проще алгоритма попарного сравнения через два вложенных цикла. Если это переводить в нампай, то нужно будет сделать матрицу дистанций между частицами, итерировать эту матрицу поэлементно, сравнивая с 2*радиус, получить матрицу флагов, и потом каким-то образом (если это вообще возможно) переходить к элементам матрицы скоростей, которые нужно изменить. В результате, скорее всего, получится больше overhead, чем в Цытоне с итерацией с помощью вложенных циклов.

Та же ссылка, которую вы приводили выше, говорит, что цыклы в Цытоне быстрее нампаевской итерации.

PS Как неспециалист, я удивляюсь популярности Питона. Как только нужно что-то серьезное, обязательно обращаются к С. Все объяснения популярности Питона в интернетах сводятся к 1) простой синтаксис, 2) динамически-типовый, 3) легче выучить. По п. 1 я мог бы согласиться, если бы смешение пробелов и табов не приводило к проблемам. По п. 2: а что в этом хорошего? По п. 3: кому легче и по сравнению с чем? ...Мне кажется, что если бы в университетах не учили студентов Питону, то никто бы про него и не вспоминал.

[flip_flop]

Нет, Cython полезен, никто не спорит. Но NumPy в себе несёт эффективную работу с массивами, матрицами и векторами и имплементацию эффективных библиотек. Не только для вложенных циклов В моём случае в одно время это (Python+NumPy+SciPy+matplotlib+Pandas) былo заменoй Матлаба для разных задач численного анализа при одновременных возможностях высокоуровневого языка общего назначения.

По той же ссылке - циклы в Cython быстрее NumPy для простенькой векторизации в 2 раза, но NumPy быстрее чистого Питона в 250 раз.

Теперь по пунктам и проблемам.
1) подходящий редактор/плагин будет поддерживать автоформатирование, в результате язык будет наиболее компактен и без проблем. Так что, да - простой синтаксис
2) хорошее то, что писать программу быстрее, не надо задумываться о типах, поймёт по контексту
3) согласен с тем, что легче разобраться, он интуитивный. Например, OOO мне интуитивнее в Питоне чем в C++. Возможно, это субъективно.

Впрочем, я не программист. К беседе надо привлечь профессионалов. Ау?