RS
Size: a a a
2020 May 22
VS
Коллеги, добрый день. Сделал тестик на скорость вычислений фортрана и джулии. (В деле бенчмарок доверять никому нельзя:-)). Может быть вам будет тоже интересно. https://github.com/vvshashkin/fortran_julia_bench
VS
Там ближе к концу Readme таблички с результатами. Резюме: фортран на высоких уровнях оптимизации быстрее Юлии процентов на 25-30.
VS
Правда код написан почти специально так, чтобы бить в слабое место фортрановского оптимизатора. Соотношение размера кода примерно 650 против 240 строк. Советы по коду приветствуются)
АО
Очень уж много всего, надо долго вникать.
По хорошему, надо загнать в профайлер и смотреть, где там узкие места, что-то мне подсказывает, что они найдутся.
Во-первых, почти наверняка многие вычисления можно обернуть либо @simd, либо @avx и получить заметное ускорение за счёт паралеллизации.
Во-вторых, вроде как есть места, где срезы матриц берутся, без @view они будут аллоцировать/копировать и соответственно понизят скорость.
Например вот тут: https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L81-L91
Я не знаю, что там считается, и насколько эта конкретно функция является bottleneck, но в ней явно огромное количество аллокаций происходит.
По хорошему, надо загнать в профайлер и смотреть, где там узкие места, что-то мне подсказывает, что они найдутся.
Во-первых, почти наверняка многие вычисления можно обернуть либо @simd, либо @avx и получить заметное ускорение за счёт паралеллизации.
Во-вторых, вроде как есть места, где срезы матриц берутся, без @view они будут аллоцировать/копировать и соответственно понизят скорость.
Например вот тут: https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L81-L91
Я не знаю, что там считается, и насколько эта конкретно функция является bottleneck, но в ней явно огромное количество аллокаций происходит.
VS
Очень уж много всего, надо долго вникать.
По хорошему, надо загнать в профайлер и смотреть, где там узкие места, что-то мне подсказывает, что они найдутся.
Во-первых, почти наверняка многие вычисления можно обернуть либо @simd, либо @avx и получить заметное ускорение за счёт паралеллизации.
Во-вторых, вроде как есть места, где срезы матриц берутся, без @view они будут аллоцировать/копировать и соответственно понизят скорость.
Например вот тут: https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L81-L91
Я не знаю, что там считается, и насколько эта конкретно функция является bottleneck, но в ней явно огромное количество аллокаций происходит.
По хорошему, надо загнать в профайлер и смотреть, где там узкие места, что-то мне подсказывает, что они найдутся.
Во-первых, почти наверняка многие вычисления можно обернуть либо @simd, либо @avx и получить заметное ускорение за счёт паралеллизации.
Во-вторых, вроде как есть места, где срезы матриц берутся, без @view они будут аллоцировать/копировать и соответственно понизят скорость.
Например вот тут: https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L81-L91
Я не знаю, что там считается, и насколько эта конкретно функция является bottleneck, но в ней явно огромное количество аллокаций происходит.
Спасибо! @simd это же аналог openmp? Туда я лезть пока не хочу, ясно, что так оба варианта можно примерно одинаково ускорить. @avx -я думал происходит автоматом, попробую. Periodic-bc тоже причешу во view
VG
Не уверен насчет этого кода, что тут без аллокаций обходится:
f0.q .= a.*f1.q.+b.*f2.q
VG
в Джулии есть инплейс-операции для векторов типа mul!
АО
Ну, в этом как раз и есть прелесть Джулии, что не надо лезть, просто перед циклом ставишь @simd и дальше она всё сделает самостоятельно.
simd - это векторизация циклов
https://juliacomputing.com/blog/2017/09/27/auto-vectorization-in-julia.html
simd - это векторизация циклов
https://juliacomputing.com/blog/2017/09/27/auto-vectorization-in-julia.html
VS
Не уверен насчет этого кода, что тут без аллокаций обходится:
f0.q .= a.*f1.q.+b.*f2.q
А эта строка не должна оптимизироваться в цикл? В фортране так и происходит.
VS
Ну, в этом как раз и есть прелесть Джулии, что не надо лезть, просто перед циклом ставишь @simd и дальше она всё сделает самостоятельно.
simd - это векторизация циклов
https://juliacomputing.com/blog/2017/09/27/auto-vectorization-in-julia.html
simd - это векторизация циклов
https://juliacomputing.com/blog/2017/09/27/auto-vectorization-in-julia.html
В фортране тоже, перед циклом !$omp do :)
VG
А эта строка не должна оптимизироваться в цикл? В фортране так и происходит.
надо проверять в профилировщике на отсутствие аллокаций
АО
В любом случае, раз есть, то почему не воспользоваться?
VS
@avx просто так не завелось, разбираюсь
VG
a = 3.
b = 4.
f0 = zeros(1000,2)
f1 = randn(1000,2)
f2 = randn(1000,2)
function mult1!(f0, f1, f2, a, b)
f0 = a.*f1 .+ b.*f2
return f0
end
function mult2!(f0, f1, f2, a, b)
@. f0 = a*f1 + b*f2
return f0
end
@time mult1!(f0, f1, f2, a, b) # 0.000007 seconds (1 allocation: 15.750 KiB)
@time mult2!(f0, f1, f2, a, b) # 0.000005 seconds
VS
Андрей, Виктор, спасибо! Добавил view, @avx, там, где оно просто поставилось. С простой потоковой схемой время уменьшилось 4.0 -> 3.3 (догнали фортран), со сложной схемой 14.6 -> 13.8
VS
Виктор, в mult1 после f0 точка не нужна?
VS
Если интересно, завтра отпишусь по работе с профайлером и добавлением @avx в "горячий" цикл(пока не получилось)
VG
Да, с точкой действительно аллокаций нет
VG
но вообще не помешает запустить с Juno.@profiler