Есть несколько возможных причин, например, float32, в целом Python или не самое производительное железо (R3600X). Думаю, основная проблема, помимо железа — это, конечно, Python, про что я написал в статье.
Возможно, вы не в полной мере осознаёте, насколько много вычислений требуется. Возьмём за пример ваши 200 на 200 точек — это один слой, но для каждой точки считается интеграл по предыдущему (в реализации учитывались все точки предыдущего слоя), нетрудными вычислениями получаем 1,6 * 10^9 в однопоток, пусть у меня 12 потоков, это ~ 10^8, и это не учитывая сложности вычислений. Проведя сравнение на i++ 10^8 раз, я получаю различие в ~78 раз (6с против 0.077c) по сравнению с C++. Сравнительные скорости работы именно torch-операций на разных языках я не сравнивал, но предполагаю, что в этом аспекте языки скорее покажут более схожие результаты в силу особенностей Python-библиотек.
Таким образом, даже в идеальной вселенной, где Python показывает себя в 75 раз хуже, время работы с 10 минут сократится до 8 секунд, но никак не до долей секунды. В реальном же мире, где Torch не наследуют проблем языка по части производительности и в силу того, что фактически сами Python операции занимают колоссально меньшую часть от времени работы программы, по сравнению с остальными вычислениями, сомневаюсь, что прирост будет больше, чем в 10–15 раз (даже такие числа я нахожу крайне преувеличенными), что даёт около минуты в C++ реализации. Это, конечно, куда лучше, но с вашим тезисом про «доли секунды» я не могу согласиться.
В прочем, я готов его принять, если вы приведёте примеры реализации, где подобная производительность достигается на сравнимом железе.
Вы правы, я забыл поменять подпись к оси, и да, интенсивность исходного поля равна 1, впрочем, этот параметр настраиваемый.
Касательно выбора дискретизации, на данный момент она задаётся вручную для каждого слоя. Для представленных результатов она подбиралась из расчёта, что на каждую из интересующих зон Френеля попадает хотя бы 5–7 точек, если смотреть по диаметру.
Если я правильно вас понял, вы считаете, что - это индикатор (поправьте, если это не так), думаю, в такой постановке задачи предложенное решение довольно удачно и действительно решает проблему. Однако относительно общей задачи, где возможно наличие нескольких перегородок, входной слой не всегда представляет собой индикатор, из-за чего аналитическое решение кажется мне затруднительным. Наверное, можно было бы добавить особенное поведение, включающее ваше замечание, для случая, когда pipeline замечает лишь одну перегородку — это помогло бы повысить качество получаемых изображений.
Есть несколько возможных причин, например, float32, в целом Python или не самое производительное железо (R3600X). Думаю, основная проблема, помимо железа — это, конечно, Python, про что я написал в статье.
Возможно, вы не в полной мере осознаёте, насколько много вычислений требуется. Возьмём за пример ваши 200 на 200 точек — это один слой, но для каждой точки считается интеграл по предыдущему (в реализации учитывались все точки предыдущего слоя), нетрудными вычислениями получаем 1,6 * 10^9 в однопоток, пусть у меня 12 потоков, это ~ 10^8, и это не учитывая сложности вычислений. Проведя сравнение на i++ 10^8 раз, я получаю различие в ~78 раз (6с против 0.077c) по сравнению с C++. Сравнительные скорости работы именно torch-операций на разных языках я не сравнивал, но предполагаю, что в этом аспекте языки скорее покажут более схожие результаты в силу особенностей Python-библиотек.
Таким образом, даже в идеальной вселенной, где Python показывает себя в 75 раз хуже, время работы с 10 минут сократится до 8 секунд, но никак не до долей секунды. В реальном же мире, где Torch не наследуют проблем языка по части производительности и в силу того, что фактически сами Python операции занимают колоссально меньшую часть от времени работы программы, по сравнению с остальными вычислениями, сомневаюсь, что прирост будет больше, чем в 10–15 раз (даже такие числа я нахожу крайне преувеличенными), что даёт около минуты в C++ реализации. Это, конечно, куда лучше, но с вашим тезисом про «доли секунды» я не могу согласиться.
В прочем, я готов его принять, если вы приведёте примеры реализации, где подобная производительность достигается на сравнимом железе.
Вы правы, я забыл поменять подпись к оси, и да, интенсивность исходного поля равна 1, впрочем, этот параметр настраиваемый.
Касательно выбора дискретизации, на данный момент она задаётся вручную для каждого слоя. Для представленных результатов она подбиралась из расчёта, что на каждую из интересующих зон Френеля попадает хотя бы 5–7 точек, если смотреть по диаметру.
Если я правильно вас понял, вы считаете, что
- это индикатор (поправьте, если это не так), думаю, в такой постановке задачи предложенное решение довольно удачно и действительно решает проблему. Однако относительно общей задачи, где возможно наличие нескольких перегородок, входной слой не всегда представляет собой индикатор, из-за чего аналитическое решение кажется мне затруднительным. Наверное, можно было бы добавить особенное поведение, включающее ваше замечание, для случая, когда pipeline замечает лишь одну перегородку — это помогло бы повысить качество получаемых изображений.