PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 25 сен 20 12:13

Часовой пояс: UTC + 4 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: 3 мар 09 18:13 
Не в сети

Зарегистрирован: 30 ноя 05 16:09
Сообщения: 130
Откуда: Ростов-на-Дону
Падение производительности происходит.
Не в такой мере как у Вас, но очень значительно.
Я вставил вычисление производительности и вот что получилось:

N time Mflops
2000 46.98 340.48
2048 177.66 96.67
2100 57.63 321.31


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 мар 09 18:21 
Не в сети

Зарегистрирован: 30 ноя 05 16:09
Сообщения: 130
Откуда: Ростов-на-Дону
Мне не кажется, что вопрос исчерпан.
То что, программа не оптимизирована, не
объясняет, почему происходит падение производительности
при одной конкретной размерности матрицы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 мар 09 18:49 
Не в сети

Зарегистрирован: 28 май 07 12:10
Сообщения: 47
Откуда: ИПС РАН
Дацюк В.Н. писал(а):
почему происходит падение производительности
при одной конкретной размерности матрицы.


Точнее, для N кратного 512.

У меня тут другой вопрос возник в связи с перестановками
циклов:
на странице http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
есть ключ -floop-interchange.
Однако, в gcc 4.3.0 он почему-то не работает:

Код:
$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)

$ gcc -O3 -floop-interchange -o mm_float2 mm_float2.c
cc1: error: unrecognized command line option "-floop-interchange"


Есть у кого-нибудь соображения по этому поводу?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 мар 09 20:15 
Не в сети

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
YurySerdyuk писал(а):
Код:
$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)

$ gcc -O3 -floop-interchange -o mm_float2 mm_float2.c
cc1: error: unrecognized command line option "-floop-interchange"


Есть у кого-нибудь соображения по этому поводу?

Во введении в документации читаем: "It corresponds to the compilers (GCC) version 4.4.0."


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 мар 09 21:53 
Не в сети

Зарегистрирован: 30 дек 08 11:52
Сообщения: 6
Хм, размер кеша L2 и его ассоциативность для испытуемого(ых) процессоров огласить можете?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 4 мар 09 0:57 
Не в сети

Зарегистрирован: 30 ноя 05 16:09
Сообщения: 130
Откуда: Ростов-на-Дону
Я выполнял замеры на DELL OptiPlex 755
CPU
model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
stepping : 11
cpu MHz : 2659.969
cache size : 4096 KB


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 4 мар 09 12:08 
Не в сети

Зарегистрирован: 30 ноя 05 16:09
Сообщения: 130
Откуда: Ростов-на-Дону
В завершение этой дискусии хочу сказать, что такой
странный эффект наблюдается только для этой конкретной
реализации алгоритма. Переписанный немного по другому,
с использованием двухмерных массивов работает вполне
адекватно. Производительность немного колеблется вблизи
таких кратных точек, но весьма незначительно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 4 мар 09 13:23 
Не в сети

Зарегистрирован: 30 дек 08 11:52
Сообщения: 6
Есть большое подозрение, что дело в банальном эффекте "буксования" L2.

У C2D E6750 L2 предположительно 16-way set associative. Можно руками посмотреть, в какие банки/строки попадают данные. Скорее всего получится, что элементы матриц просто претендуют на одну и ту же ячейку кеш-памяти. icc об этом знает и проводит перестановку циклов, что и приводит к лучшему эффекту, как тут было показано.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 5 мар 09 15:48 
Не в сети

Зарегистрирован: 28 май 07 12:10
Сообщения: 47
Откуда: ИПС РАН
Дацюк В.Н. писал(а):
Переписанный немного по другому,
с использованием двухмерных массивов работает вполне
адекватно.

Если под двумерным массивом понимается одномерный массив указателей на одномерные массивы, то такой вариант работает
более, чем в 3 раза медленнее, чем чистые одномерные массивы,
что неприемлемо:

а) одномерный случай:
Код:
$ ./mm_float3 1000
N = 1000 Elapsed time = 0.430000
$ ./mm_float3 2000
N = 2000 Elapsed time = 3.700000
$ ./mm_float3 2500
N = 2500 Elapsed time = 6.970000


б) двумерный случай
Код:
$ ./mm_float2D 1000
N = 1000 Elapsed time = 1.130000
$ ./mm_float2D 2000
N = 2000 Elapsed time = 11.600000
$ ./mm_float2D 2500
N = 2500 Elapsed time = 22.600000


Код:
model name      : Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
stepping        : 6
cpu MHz         : 3000.000
cache size      : 4096 KB


Кроме того, данный подход не решает проблему принципиально -
для одномерных массивов при определенных условиях
снова может случиться "cache trashing".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 5 мар 09 16:19 
Не в сети

Зарегистрирован: 28 май 07 12:10
Сообщения: 47
Откуда: ИПС РАН
Кому еще не надоела эта тема, могут быть интересны следующие данные, полученные экспериментально.

На процессоре
Код:
model name      : Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
stepping        : 6
cpu MHz         : 3000.000
cache size      : 4096 KB

даже перестановка внутренних циклов не помогает -
неважно, то ли сделанная компилятором, то ли вручную:
Код:
$ icc -O3 -o mm_float3 mm_float3.c
mm_float3.c(23): (col. 3) remark: LOOP WAS VECTORIZED.
mm_float3.c(33): (col. 4) remark: LOOP WAS VECTORIZED.
mm_float3.c(33): (col. 4) remark: LOOP WAS VECTORIZED.
mm_float3.c(33): (col. 4) remark: LOOP WAS VECTORIZED.
$ ./mm_float3 2000
N = 2000 Elapsed time = 3.700000
$ ./mm_float3 2048
N = 2048 Elapsed time = 12.590000
$ ./mm_float3 2100
N = 2100 Elapsed time = 4.160000


Кроме того, обнаружилось, что при "хороших"
размерностях матриц процессор Xeon 5160
в 2,5 раза быстрее на перемножении матриц,
чем Xeon E5472, используемый на узлах кластера
СКИФ-МГУ:

Код:
model name      : Intel(R) Xeon(R) CPU           E5472  @ 3.00GHz
stepping        : 6
cpu MHz         : 3000.115
cache size      : 6144 KB


N Xeon5160 XeonE5472
------------------------------------------------
1500 1.51 3.37
2000 3.70 9.21
2500 6.97 17.67

C чего бы это?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 5 мар 09 19:04 
Не в сети

Зарегистрирован: 13 сен 08 18:39
Сообщения: 74
Откуда: Москва
YurySerdyuk писал(а):
Кроме того, обнаружилось, что при "хороших"
размерностях матриц процессор Xeon 5160
в 2,5 раза быстрее на перемножении матриц,
чем Xeon E5472, используемый на узлах кластера
СКИФ-МГУ:

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

А вот результаты с 5160 непонятны.... надо взять этот же бинарник скопировать и запустить на другом процессоре, может быть там тот же эффект будет...

_________________
Дмитрий О. Коломиец.
IBM // МГУ, физфак, каф. математики.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 4 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB