Свежие комментарии
| Title | Comment |
|---|---|
| Ололо, марат! |
Ололо, марат! |
| Ого! 1032Mpix/sec (16.5gb/sec) Это не развернутый вариант, |
Ого! 1032Mpix/sec (16.5gb/sec) И не ассемблер, а intrinsics, хотя разницы быть не должно. |
| Верхи мне не светят (в смысле |
Верхи мне не светят (в смысле личной практики), я не HPC-специалист, просто мимо проходил. А вот 40-80 машин, вроде той, что поминается в самом моем посте - вполне могут оказаться на пути (с infiniband, вестимо). А с ними попасть в низы топ500 вполне реально. |
| А в верхах - престиж. Вон |
А в верхах - престиж. Вон японцы на K больше 90 выжали - все ахают. |
| Тельняшку Расковалов рвал на груди, обещая порвать Ломоносов |
Тельняшку Расковалов рвал на груди, обещая порвать Ломоносова на тряпки? Вы не обижайтесь лишнего, я просто в ППБ вбил слово HPlinpack и наткнулся на тот пост.... |
| "получившая в 600 раз меньше" - не очень-то и хотелось :) |
"получившая в 600 раз меньше" - не очень-то и хотелось :) |
| В самых низах Top500 - один |
В самых низах Top500 - один процент это мест 15. Несколько процентов того стоят. |
| Порядка 75% для двух GPU, |
Порядка 75% для двух GPU, порядка 50% - для четырех. "порядка" - потому что неясно, как учитывать в Rpeak те CPU cores, которые занимаются вводом-выводом. Можно формально (и тогда Rpeak будет на 100-110Gflops больше), а можно "сделать скидку на занятость" и тогда поменьше. Rpeak одного GPU - 600 gflops, потому что они у нас на 750Mhz, а не на родных 830 (температурный режим....) |
| А пардон. |
Не обратил внимания, что это Франкфуртовский университет. |
| На моём ноуте быстрее, хотя ненамного (8700 MB/s vs 8500 MB/ |
На моём ноуте быстрее, хотя ненамного (8700 MB/s vs 8500 MB/s) и я не уверен, что разница статистически значима. В общем случае это зависит от множества параметров (сколько массивов данных читает/пишет программа, сколько буферов загрузки и записи есть в процессоре, сколько cache misses может одновременно обрабатывать контроллер кэша, сколько открытых DRAM страниц может держать контроллер памяти, и т.д.). Я как раз делаю ресёрч на эту тему |
| 10-15 минут все же маловато, |
10-15 минут все же маловато, на мой взгляд. Там коммуникаций заметно. Вот если для часовой - то можно сказать, что будут близки и для 2*N, 3*N, сколько там памяти хватит. Но это так, навскидку, я линпак крутил, но все ж таки не очень глубоко. На кластере гораздо сильнее играет роль равномерность распределения нагрузки, поэтому если уж мы ее нормально распределили, то дальше все проще. Но ради единиц процентов все равно придется крутить отдельно. |
| В практическом смысле |
В практическом смысле интересует следующий вопрос, если вы сталкивались: - если мы "накрутили параметры HPL" для задачи размера N (достаточно большого, пусть она 10-15 минут считается на имеющемся кластере) В пределах одной ноды оно не вполне так и для каждого размера приходится что-то переподбирать, но по счастью самая большая влезающая задача (122к) считается где-то минут 15, за сутки вариантов перебрать можно прилично. |
| Ага, пощупаю. А действительно работать в два потока "с нача |
Ага, пощупаю. А действительно работать в два потока "с начала до середины" и "с середины до конца" - быстрее? |
| Ок, вот <a href="http://pastebin.com/rbpdgEyz">новая версия< |
Ок, вот новая версия для 4-х компонентных пискелей на выходе. Теперь |
| Да я понимаю, что MKL - CPU |
Да я понимаю, что MKL - CPU only. Это я к тому, что умельцы на CPU (тем более на одной машине) выжимают процентов до 90. Про GPU же тоже речь про умельцев идет. А памяти надо много, да, тогда будет лучше. |
| Угадал с трех раз :) |
Угадал с трех раз :) |
| Браво! |
Браво! |
| Дело у меня скорее в другом: |
Дело у меня скорее в другом: эффективность заметно растет с ростом задачи, но на i7 у меня памяти мало (всего 12Gb), а на оптероне ее хоть и много, но задачи больше чем ~40k пускать считаться на CPU скучно, слишком уж долго. Но намек понял, задачу размером ~120k на оптероне как-нибудь запущу, чисто из интереса. Это часа на два-три... |
| О, другое дело. Тогда 2x6990, ибо у AMD MULADD_64 в 4 раза " |
О, другое дело. Тогда 2x6990, ибо у AMD MULADD_64 в 4 раза "медленнее", чем MULADD :) |
| На i7 (не AVX) я пробовал - и |
На i7 (не AVX) я пробовал - и получил примерно столько же, не кардинальная разница, может процентов 5. Но если смотреть на теги/рубрику данного сообщения, то становится понятным, что MKL нерелевантна, основной счет все едино не на CPU. |
| Это двойная точность, не одинарная. |
Это двойная точность, не одинарная. |
| Если в вместо GotoBLAS взять |
Если в вместо GotoBLAS взять MKL, результаты будут получше, это что сходу. Дальше - надо крутить всякие параметры самого HPL, так тяжело обсуждать. |
| Ну и нормально. Современный GPU. |
Ну и нормально. Современный GPU. |
| На перемножении матриц та же система - 2.2 терафлопса. |
На перемножении матриц та же система - 2.2 терафлопса. |
| Ну я совсем не специалист, |
Ну я совсем не специалист, просто жизнь заставила, что вижу, то и пою. А вижу я на CPU следующее. Без всяких кластеров, в коих я тем более не специалист, просто single node: Правда про оптерон я знаю почти точно, а про i7 подозреваю, что они уперты в memory bandwidth (уменьшаем число задействованных ядер и производительность почти не падает). |
| А, действительно, это же Linpack, а не перемножение матриц, |
А, действительно, это же Linpack, а не перемножение матриц, стормозил :) |
| Ну не надо так |
Ну не надо так пессимизировать. На хорошем интерконнекте 83-85% все-таки на CPU получается. |
| Точность - двойная. |
Точность - двойная. А интеловского в этих машинах - только контроллер Ethernet |
| Ну все-таки тег gpgpu есть у сообщения :) На CPU оценка бол |
Ну все-таки тег gpgpu есть у сообщения :) На CPU оценка более-менее правильная,да: 3 гигагерца x 4 flop/clock - это 12 гигафлопс пиковой на ядро, реально на HPL получить процентов 75 т.е. 9glops, 136 ядер. |
| Не, тот код меняет 3 компоненты, а 4-ю просто оставляет как |
Не, тот код меняет 3 компоненты, а 4-ю просто оставляет как есть. В том коде просто нету внешнего цикла, который img+=4 Что касается ошибки, то я просто накормил повторяющимися входными данными (1,2,3,4) и ожидал увидеть повторяющиеся выходные, а в ymm4 было другое. Возможно, я просто неаккуратно перенес (хотя проверил). Хрен с ним, идея что можно горизонтально складывать для скалярного произведения - понятна, а остальное неважно. |
Pages
