Как стать автором
Обновить
13
0
Владимир Коляденко @vlanko

Программист

Отправить сообщение
Думаю, имелось в виду, что массив из 3-6 компонент не кратен 4м.
Но я мог бы сложить в одну матрицу Ez, Hx, Hy, e — как раз 2^2
У меня 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-мерный цикл полностью на вычитание матриц:
код
Ez0(2:end-1, 2:tt) = Ez(2:end-1, 2:tt)+e(2:end-1, 2:tt).*(Hx(2:end, 1:tt-1)-Hx(2:end, 2:tt)+Hy(2:end, 2:tt)-Hy(1:end-1, 2:tt));
Hx0(1:end, 1:tt) = Hx(1:end, 1:tt) + dH *(Ez(1:end-1, 1:tt) - Ez(1:end-1, 2:tt+1));
Hy0(1:end, 1:tt) = Hy(1:end, 1:tt) + dH *(Ez(2:end, 1:tt) - Ez(1:end-1, 1:tt));


Выигрыш от 3,1х для малых до 3,8х до больших матриц. Если оптимизировать идеально остальное, может выжмется 4,5х.
В любом случае, спасибо за идею.
Чужое решение не запоминается.

Что-то в этом есть…
К тому-же, найденный на Стеке решения часто далеко не оптимальны.
2.У меня и у https://habrahabr.ru/post/319216/#comment_10005284
1-мерный массив уменьшает производительность.
1. А вот хранить все локально — интересный вариант. Только все циклы придется ужасно переписывать.
ДА
только ttt = tt / 4;
и ваше условие j <= ttt.
А пройти мы должны были до 56.
В моем случае я вообще не вижу смысла в таком разворачивании циклов. У меня запас производительности процессора примерно в 48 раз выше, чем скорость памяти.
Вы уменьшили в 4 раза.
Я же посмотрел визуализацию на Яве. Фигня была именно в том, что обрабатывается только первая четверть картинки.
В вашем коде:
auto ttt = tt / 4;
		for (int j = 2; j <= ttt; j+=4)
		{
			int j1 = j+0;
			int j2 = j+1;
			int j3 = j+2;
			int j4 = j+3;

Нужно:
а) int j1 = j * 4+0;
или б) j <= tt- 4
или в) j <= ttt * 4. (Но эти два варианта глупые)
В вашем коде максимальное значение переменных tt / 4+3 << tt
j <= ttt
ttt = tt / 4;
да, float — это мой глюк. Пока циклы были <, а не <= все было нормально. Заменю все на инт.
Судя по цифрам, у ассемблерного сайта средняя загрузка процессора была 1% а самый тяжелый день.
1. Два основных цикла тратят до 84-85% времени (на Джаве также)
2. Да, компиляторы нынче умные
Профилировщик в С++ никакой, хотя вроде в VisualStudio смотрел.
После компиляции бинарник мало отличается. Разница производительности в пределах погрешности.
Пока на Джаве разворачивание только Е дало падение производительности на 3 % (в пределах погрешности)
Ахтунг!
Применил ваш код, и вышла фигня.
Потом понял:
ttt = tt / 4;
Вы просто уменьшили объем вычислений в 4 раза
Уточняю. Нашел книжку 2006года по распараллеливанью.
Там ФДТД используют на Fortran 90 с MPI
А на БПФ я наезжаю потому, что Матлаб умеет как-угодно без существенных потерь скорости.
Да, но у моих процей только 6-8 МБ кеша.
Малые задачи у меня выполняются быстрее — эквивалент 30 ГБ/сек против 17 ГБ/сек, (память 20около).
То есть лезут в кеш.
Но тупое деление большой области на 4 куска по і делает немного хуже.
Буду проверять развернутые циклы.
Потоки — стандартные из C++11.
Именно в mingw нормально работают.
Да, одномерный массив у меня тоже давал падение скорости.
Имхо, ускорение слабое, потому что даже 2-поточный код близок к скорости памяти.
Да, все именно так и планировалось. Вопрос у меня в том, можно ли на С++ эффективнее порождать потоки (с меньшими затратами)

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность