срезы делают копию по умолчанию, насколько я знаю

Да

@simd не дает значимого эффекта, к сожалению. Даже с вариантом, когда потоковая схема "захардкожена" внутрь цикла. Там в функции плохие операторы стоят, типа sign

Правильно ли я понимаю, avx это тоже самое, но специфичное для интелевых процессоров?

Насколько я понимаю, @simd (как операция) появился в языке достаточно давно, @avx это что-то более новое и экспериментальное (и вообще разрабатывается не core командой). Насколько я знаю, @avx более сложно устроен и использует более широкий набор операций, но за счёт этого у него похуже покрытие.

Спасибо. У ifort есть ключики -xSSE, -xAVX, -xAVX512. Судя по ассемблеру, последние 2 включают автовекторизацию циклов с использованием продвинутых векторных регистров и комманд. Полсле  -x AVX512 код запускается только на свежих интелевых процессорах. С openmp это никак не интерферирует. @simd, видимо, аналог более старого xSSE.

Да.

Ну, на самом деле процентов 20-30 медленнее - это вполне реально.
Насколько я помню, обычно говорится, что Джулия - это где-то 1.1-1.2 от аналогичного сишного кода.

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

Поменял везде @avx на @simd результат тотже

Хотя всё равно думаю, что если постараться то можно ещё немного выжать 😊 Но это конечно отдельный вопрос, где проходит граница между оптимизацией и другим по сути алгоритмом.

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

Это я про https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L11-L12

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

А где определена функция fluxf? Никак не могу найти её в тексте.

Она передается сверху как аргумент в operator

На данный момент это либо up4 либо weno5

По принципу ну кисонька, еще капельку, можно и с фортрана выжать прлизводительности, но принципиально это ничего не измегит

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

https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L28 - вот это место ещё неприятное. Здесь я так понимаю строчка вырезается? Так как Julia column major, то это плохо влияет на скорость вычислений.

Если можно это как-то изменить, то тоже может помочь.

Можно было бы аллоцировать flx fly и q в operator.jl, но тогда код будет уже менее красив, чем фортрановский), а этого не хочется. В фортране аналоги этих массивов- automatic arrays, тоже аллоцируются при каждом вызове функции, но если повезет, то в стэке, а не в куче.

Да, это самое противное место всего алгоритма, но от этого никуда не денешься ни в фортране, ни в джулии

Если памяти не жалко, то можно конечно поменять
https://github.com/vvshashkin/fortran_julia_bench/blob/master/advection/julia_code/operator.jl#L90

с

return q1

на

return q1, permutedims(q1)

и дальше уже пользоваться второй матрицей. Ну и время затраченное на транспонирование может съесть весь прирост от использования правильного размещения в памяти.

Но это конечно тоже выглядит как читерство.

return q1

return q1, permutedims(q1)

Обычно эта игра не стоит того (по фортрановской практике), но попробовать можно, а память -да, не жалко