Необъяснимые накладные расходы Xeon-Phi

Я пытаюсь запустить этот код с этими разными размерами n на Xeon Phi KNC. Я получаю тайминги, как показано в таблице, но я понятия не имею, почему я испытываю эти колебания. Не могли бы вы провести меня через это? Заранее спасибо.

КОД:

program prog
  integer, allocatable :: arr1(:), arr2(:)
  integer :: i, n, time_start, time_end
  n=481
  do while (n .le. 481000000)
    allocate(arr1(n),arr2(n))
    call system_clock(time_start)
    !dir$ offload begin target(mic)
    !$omp SIMD 
    do i=1,n
       arr1(i) = arr1(i) + arr2(i)
    end do
    !dir$ end offload 
    call system_clock(time_end)
    write (,) "n=",n," time=",time_end-time_start
    deallocate(arr1,arr2)
    n = n*10
  end do
end program

ПОЛУЧЕННЫЕ РЕЗУЛЬТАТЫ:

 n=         481  time=        8881
 n=        4810  time=          75
 n=       48100  time=          53
 n=      481000  time=         261
 n=     4810000  time=        1991
 n=    48100000  time=       18912
 n=   481000000  time=      188203

person Gal Oren    schedule 06.07.2018    source источник
comment
Настройки: #!/bin/bash #SBATCH -N 1 #SBATCH -o out_122 #SBATCH --exclusive export MIC_KMP_AFFINITY=verbose,granularity=fine,scatter export MIC_OMP_NUM_THREADS=122 ./prog.exe   -  person Gal Oren    schedule 06.07.2018
comment
sbatch -p xphi -N 1 --exclusive run_par.sh, а все настройки — в run_par.sh, а xphi — это имя устройства.   -  person Gal Oren    schedule 07.07.2018
comment
Также стоит отметить, что собственный запуск (добавление !dir$ offload begin target(mic) перед !$omp SIMD дает гораздо лучшие результаты. n= 481 time= 0 n= 4810 time= 0 n= 48100 time= 6 n= 481000 time= 55 n= 4810000 time= 455 n= 48100000 time= 4342 n= 481000000 time= 43322   -  person Gal Oren    schedule 07.07.2018
comment
При естественном запуске настройки следующие: #!/bin/bash #SBATCH -N 1 #SBATCH -o out_244_native #SBATCH --exclusive export SINK_LD_LIBRARY_PATH=...intel/compilers_and_libraries/linux/lib/mic:$SINK_LD_LIBRARY_PATH micnativeloadex ./prog.exe.MIC -e "KMP_AFFINITY=verbose,granularity=fine,scatter"   -  person Gal Oren    schedule 07.07.2018


Ответы (1)


Первая разгрузка (n=481), безусловно, будет медленной, потому что именно здесь вы выгружаете весь код и инициализируете процесс на KNC. Если вы не хотите видеть это, сделайте пустую разгрузку, прежде чем начать синхронизировать вещи.

На верхнем уровне (>=481000) все кажется нормальным; каждый прогон примерно в 10 раз медленнее, чем предыдущий, поэтому единственная странность теперь — масштабирование более низких. Возможно, что-то из этого связано с дисбалансом нагрузки. Если у вас 60-ядерный процессор и вы используете 4T/C (вы не предоставили нам эту информацию), 4810 итераций => ~20 итераций/ядро, что означает, что производительность SIMD, вероятно, будет низкой, поскольку у вас 16 дорожек. Учитывая смещение, вы можете выполнять только ввод и вывод, и ничего на полную ширину!)

person Jim Cownie    schedule 09.07.2018