У меня 32-битный gcc 4.92
Включение опции -mfpmath=sse не изменяет ничего.
Полный набор ваших опций увеличивает время на 5%
Если что, мои опции mingw32-g++.exe -Wall -fexceptions -O2 -march=corei7-avx -O3 -std=c++11
Буду пытаться 64-битный компилятор. Под винду сложно найти нормальное.
Провел собственный анализ.
Много тратит запись элемента массива. Если принять время выполнения 3 циклов за 100у.е., то
каждая запись(+=) из 3х тратит 20,
запись на даблах 31 (просто для сравнения)
однократное чтение 6-7
пятикратное чтение 27
(оценки приблизительны, внимательный читатель поймет, что мы уже ниже 0)
Сделал еще экстремальнее — заменил 4 массива на int8_t (или это плохой тип?), с сохранением корректности всей математики. Выигрыш при 4096х700 1,26 раза. Чем больше область, тем выше.
Почему же был высокий прирост от 64бита к 32?
1024*700 — это тестовая задача, какую смог дождаться в Матлабе. С++ детально не изучал, в Джаве наибольший упор в скорость памяти при 4096х500
2.У меня и у https://habrahabr.ru/post/319216/#comment_10005284
1-мерный массив уменьшает производительность.
1. А вот хранить все локально — интересный вариант. Только все циклы придется ужасно переписывать.
В моем случае я вообще не вижу смысла в таком разворачивании циклов. У меня запас производительности процессора примерно в 48 раз выше, чем скорость памяти.
1. Два основных цикла тратят до 84-85% времени (на Джаве также)
2. Да, компиляторы нынче умные
Профилировщик в С++ никакой, хотя вроде в VisualStudio смотрел.
А на БПФ я наезжаю потому, что Матлаб умеет как-угодно без существенных потерь скорости.
Да, но у моих процей только 6-8 МБ кеша.
Малые задачи у меня выполняются быстрее — эквивалент 30 ГБ/сек против 17 ГБ/сек, (память 20около).
То есть лезут в кеш.
Но тупое деление большой области на 4 куска по і делает немного хуже.
Буду проверять развернутые циклы.
Потоки — стандартные из C++11.
Именно в mingw нормально работают.
Да, одномерный массив у меня тоже давал падение скорости.
Имхо, ускорение слабое, потому что даже 2-поточный код близок к скорости памяти.
Но я мог бы сложить в одну матрицу Ez, Hx, Hy, e — как раз 2^2
Включение опции -mfpmath=sse не изменяет ничего.
Полный набор ваших опций увеличивает время на 5%
Если что, мои опции mingw32-g++.exe -Wall -fexceptions -O2 -march=corei7-avx -O3 -std=c++11
Буду пытаться 64-битный компилятор. Под винду сложно найти нормальное.
Много тратит запись элемента массива. Если принять время выполнения 3 циклов за 100у.е., то
каждая запись(+=) из 3х тратит 20,
запись на даблах 31 (просто для сравнения)
однократное чтение 6-7
пятикратное чтение 27
(оценки приблизительны, внимательный читатель поймет, что мы уже ниже 0)
Почему же был высокий прирост от 64бита к 32?
1024*700 — это тестовая задача, какую смог дождаться в Матлабе. С++ детально не изучал, в Джаве наибольший упор в скорость памяти при 4096х500
Выигрыш от 3,1х для малых до 3,8х до больших матриц. Если оптимизировать идеально остальное, может выжмется 4,5х.
В любом случае, спасибо за идею.
Что-то в этом есть…
К тому-же, найденный на Стеке решения часто далеко не оптимальны.
1-мерный массив уменьшает производительность.
1. А вот хранить все локально — интересный вариант. Только все циклы придется ужасно переписывать.
только ttt = tt / 4;
и ваше условие j <= ttt.
А пройти мы должны были до 56.
Я же посмотрел визуализацию на Яве. Фигня была именно в том, что обрабатывается только первая четверть картинки.
В вашем коде:
Нужно:
а) int j1 = j * 4+0;
или б) j <= tt- 4
или в) j <= ttt * 4. (Но эти два варианта глупые)
В вашем коде максимальное значение переменных tt / 4+3 << tt
j <= ttt
ttt = tt / 4;
2. Да, компиляторы нынче умные
Профилировщик в С++ никакой, хотя вроде в VisualStudio смотрел.
Применил ваш код, и вышла фигня.
Потом понял:
ttt = tt / 4;
Вы просто уменьшили объем вычислений в 4 раза
Там ФДТД используют на Fortran 90 с MPI
Да, но у моих процей только 6-8 МБ кеша.
Малые задачи у меня выполняются быстрее — эквивалент 30 ГБ/сек против 17 ГБ/сек, (память 20около).
То есть лезут в кеш.
Но тупое деление большой области на 4 куска по і делает немного хуже.
Буду проверять развернутые циклы.
Именно в mingw нормально работают.
Да, одномерный массив у меня тоже давал падение скорости.
Имхо, ускорение слабое, потому что даже 2-поточный код близок к скорости памяти.