не работает распараллеливание в gcc

[venco]

Missir в сообщении #1638647 писал(а):

venco в сообщении #1638645 писал(а):

А почему переменная dv одна на всех?

я пробовал заводить для неё массив res[i] но это ни на что не влияет, видимо компилятор с этим справляется сам

Зачем массив? Обьявите её локально в цикле.

[Missir]

Вот так работает, результаты выдаёт правильные, задействует оба потока. Просто нужно было объявить переменные внутри.

Используется синтаксис C

#pragma omp parallel num_threads(2)
{
  #pragma omp for
  for (int i=0; i<sampl-1; i++)
  { printf ("iteration %d, thread=%d\n", i, omp_get_thread_num());
    x[i*sampl+i]=0.0; 
    for (int j=i+1; j<sampl; j++)
    { 
      double dv=max_norm(xyz+i*N_atom*3, xyz+j*N_atom*3, iel, N_atom, N_perm);
      x[i*sampl+j]=sqrt((Sx[i]+Sx[j]-2*dv)/N_atom); x[j*sampl+i]=x[i*sampl+j];  
    }
  }  
}
 

Но главная проблема как была так и осталась. Прибавки в скорости я не вижу совершенно, что в одном потоке, что в 2-х, почти одинаково

[mihaild]

Хм. Очень странно, что гонка в dv давала такой результат. Ну да бывает, наверное...
Какое у Вас получается распределение индексов по потокам - первая половина в первом, вторая во втором?

Попробуйте посмотреть в профайлер. Но мне всё еще очень не нравится x[j*sampl+i] - прыгаем по памяти, да к тому же пишем из двух потоков в соседние адреса. К тому же, если я правильно понимаю, в цикле оттуда не читаем. Что будет с производительностью, если вообще убрать это копирование?

[Missir]

Уменьшаю число итераций внешнего цикла вот так:

Используется синтаксис C

#pragma omp parallel num_threads(2)
{
  #pragma omp for
  for (int i=0; i<sampl/2-1; i++)
  { printf ("iteration %d, thread=%d\n", i, omp_get_thread_num());
    x[i*sampl+i]=0.0;
    for (int j=i+1; j<sampl; j++)
    {
      double dv=max_norm(xyz+i*N_atom*3, xyz+j*N_atom*3, iel, N_atom, N_perm);
      x[i*sampl+j]=sqrt((Sx[i]+Sx[j]-2*dv)/N_atom); x[j*sampl+i]=x[i*sampl+j];  
    }
  }  
}
 

и время выполнения ожидаемо уменьшается, а #pragma omp for ничего не даёт. хотя эффект должен быть тем же

-- 10.05.2024, 20:36 --

mihaild в сообщении #1638660 писал(а):

Какое у Вас получается распределение индексов по потокам - первая половина в первом, вторая во втором?

да, но по порядку первыми почему то выполняются итерации 2 потока, а в конце первого, т.е. сначала большие индексы а уже потом маленькие

[mihaild]

Missir в сообщении #1638661 писал(а):

да, но по порядку первыми почему то выполняются итерации 2 потока, а в конце первого, т.е. сначала большие индексы а уже потом маленькие

Это строго? Т.е. сначала (sampl / 2, 1), ..., (sampl - 1, 1) в таком порядке, а потом (0, 0), (1, 0), ..., (sampl / 2 - 1, 1)?

[Missir]

mihaild в сообщении #1638660 писал(а):

Что будет с производительностью, если вообще убрать это копирование?

закомментировал строки с x[j*sampl+i], в скорости абсолютно никаких изменений

-- 10.05.2024, 20:41 --

mihaild в сообщении #1638663 писал(а):

Это строго?

нет не строго, но тенденция проявляется отчётливо

в общем сначала идут 0 1 1 0 1 1 0 1 1 0, т.е. одно ядро как бы перегружено, а в конце идут одни нули, те что остались

но у меня двухядерная машина, наверное так и должно быть, ведь тут и система и инет и т.д. и т.п, одно ядро подгружают

[mihaild]

А, я не заметил - у Вас же вторая половина итераций сильно быстрее - второй поток делает в 3 раза меньше работы, чем первый (хотя всё равно ускорение на четверть должно быть).
Попробуйте #pragma omp for schedule(static, что-нибудь порядка sampl / 100)

[Missir]

Скорость точно такая же, более того, запускал эту программу на 4-х ядерной машине - прибавки в скорости тоже абсолютно никакой,
вроде как бы всё и работает, но толку никакого. Но прирост в скорости ведь должен быть

[mihaild]

А у Вас же все итерации получаются независимы друг от друга? Тогда еще можно попробовать объединить внешний и внутренний цикл в один.
max_norm куда-нибудь что-то пишет, или только читает?
В загрузке системы видно что заняты два ядра, или одно?

[Missir]

Независимы, но получается так. Я пробовал делить всё поровну на 2 секции и запускал через sections
тоже все ядра как бы загружены, но эффект нулевой.
У меня есть ещё одно подозрение, а tm=clock(); вообще адекватно работает в параллельном режиме?
а то может ускорение и есть, а я его просто не вижу?

[mihaild]

А, это правильное наблюдение:)
clock замеряет процессорное время процесса. Соответственно в многопоточном варианте оно легко может идти быстрее астрономического.

[Missir]

Действительно, проблема в clock(), заменил его на time(NULL), теперь показывает в однопоточном режиме 5s, а в 2-х поточном 2 секунды. Но time() даёт целое число секунд, а как бы получить его в миллисекундах, или микросекундах??? чтобы точнее измерить

[mihaild]

В С, насколько я знаю, переносимого способа нет. На линуксе есть gettimeofday и clock_gettime, на альтернативных ОС наверное тоже что-то есть.
В C++ есть std::chrono.

[Dmitriy40]

Под виндой удобна GetTickCount().

[Missir]

mihaild в сообщении #1638672 писал(а):

На линуксе есть gettimeofday и clock_gettime

уж не знаю почему, но эти функции у меня выдают очень сомнительные результаты так, что использовать их не получилось. Пришлось обходиться time(NULL) она работает вполне корректно, проверял по секундомеру. Для точности, поместил этот фрагмент в цикл на 100 повторений. Лучше всего использовать schedule(static, 1) и максимальное число потоков nls в num_threads(nls) , оно обычно в 2 раза больше числа ядер. При таких настройках на 2-х ядерном компе получается ускорить в 2.1-2.3 раза, а на 4-х ядерном - в 4.2-4.5 раз.

-- 11.05.2024, 01:15 --

В общем похоже вопрос решен. Всем большое спасибо за помощь, особенно mihaild