Форум Академгородка, Новосибирск > Семинар NVIDIA
Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Семинар NVIDIA
Форум Академгородка, Новосибирск > Компьютеры и сети > Программирование
Страницы: 1, 2
nvidia.ru
Компания NVIDIA (http://nvidia.ru) приглашает всех заинтересованных лиц на семинар по теме «Решение инженерных и научных задач на гибридных вычислительных системах, графические процессоры и архитектура CUDA».
Место проведения: г.Новосибирск, проспект Ак. Каптюга, д. 3, Институт Нефтегазовой Геологии и
Геофизики СО РАН, Конференц-зал.Участие в семинаре бесплатное.
Оформить заявку на регистрацию можно по адресу http://www.ot.ru/ac20110421.html
По вопросам регистрации на семинар обращайтесь, пожалуйста, к Конышевой Анне: тел.: 8-916-210-60-18, e-mail: akonysheva@ot.ru
Будем рады увидеть Вас и Ваших коллег на конференции!
joyrider
Посетил сее мироприятие. Сложилось двоякое впечатление.

Понравилась вступительная презентация от Антона (NVidia).
Что не понравилось.
  • Почему-то упорно замалчивалась проблема пересылки данных (по крайней мере до кофе-брейка), которая является узким местом для вычислений на GPU
  • По-моему «слухи» о производительности и возможности архитектуры NVidia сильно преувеличины. Особенно забавно было смотреть как люди отмечали в своих презентациях ускорение в сотни раз, а некоторые даже сравнивали с однопоточным выполнением на многоядерных процессорах smile.gif. А почему бы не сравнивать с многопоточным выполнением на многоядерных процессорах? Корпорации AMD и Intel из кожи вон лезут чтобы побольше ядер запихать в процессор, а пользователь упорно не хочет их замечать? smile.gif


Теперь поконкретнее о «слухах», а точнее почему не может быть ускорения в сотни раз:
За основу возьму вот эту статью об выполнении операций с плавающей точкой для расчета пиковой производительности старого процессора Nehalem http://software.intel.com/en-us/forums/showpost.php?p=60696

Имеем 8 (float Single Precision) операций за такт на ядро x 4 ядра х 3ГГц = 96 Гфлопс

Теперь смотрим спецификацию Tesla C2050
http://www.nvidia.com/docs/IO/43395/NV_DS_...jul10_lores.pdf
Single Precision floating point performance (peak) 1.03 Tflops = 1030 Гфлопс

Разница в 10.7 раз по сравнению со старым Nehalem’ом

Допустим у нас есть двухсокетный сервер, тогда разница будет всего в 5 раз.
А если он еще построен на Westmere-Ex: 8FLOP * 10 cores * 2.4GHz * 2 sockets = 384GFLOPS и разница всего 2.68 раза
А в сравнении с таким же сервером на базе Sandy-Bridge разница будет еще меньше, так как Sandy-Bridge на одном из устройств умеет делать fused multiply-add, которую нужно считать как 2 операции с плавающей точкой и вектора в 2 раза длиннее.
однако есть мнение что FMA нет в SandyBridge. подробности здесь http://forum.academ.org/index.php?s=&showt...dpost&p=8361880

Если вы получаете разницу в сотни раз хотя бы на Nehalem, значит вы что-то неправильно делаете с процессором (не правильно используете КЭШ, веткоризуете и распараллеливаете свой код используя не тот компилятор)
alex2000
Цитата(joyrider @ 21.04.2011, 22:09) *
Посетил сее мироприятие. Сложилось двоякое впечатление.

Я, по ряду причин, на этом мероприятии не смог присутствовать.
Вам благодарность за сообщение. Один вопрос:
имеет смысл простому советскому ученому пытаться мучать эту КУДА?
Там ведь далеко все не так просто в реализации.
а затраты на разработку кода не малые
joyrider
Цитата(alex2000 @ 21.04.2011, 21:19) *
Цитата(joyrider @ 21.04.2011, 22:09) *
Посетил сее мироприятие. Сложилось двоякое впечатление.

Я, по ряду причин, на этом мероприятии не смог присутствовать.
Вам благодарность за сообщение. Один вопрос:
имеет смысл простому советскому ученому пытаться мучать эту КУДА?
Там ведь далеко все не так просто в реализации.
а затраты на разработку кода не малые

Это зависит. Если ваша задача решается стандартными методами и у вас достаточно много данных для вычислений, то ответ – ДА.
Если ваша задача решается какими-то нестандартными способами, особенно если вы работаете со старыми исходниками написаными еще в прошлом веке и вы готовы погрузиться в чтение архитектуры CUDA и у вас достаточно много данных для вычислений, то ответ – МОЖЕТ БЫТЬ

Почему большой объем данных играет большую роль?
Потому-что пересылка данных по шине с CPU на GPU это удовльствие дорогое. Пересылка по шине PCI-E x16 позволяет достич пропускной способности 8ГБ/сек (при условии что страницы памяти правильно выделены), в то время как пропускная способность оперативной памяти для CPU может достигать 32Гб/сек. Другими словами пока вы будете отправлять данные по шине и считать их на GPU может получиться что вы за то же время сможете посчитать их и на CPU.
alex2000
Цитата(joyrider @ 21.04.2011, 22:40) *
...

Там же на распараллель спец человека ставить надо. Причем обученного, иначе смысла нету
__kot2
у нвидии ее самая большая проблема по сравнению с amd это кол-во регистровой памяти. у нвидии 64 регистра на fermi, 32 на более старых. обычных 32 битных, из них элементарно вылезти, а у amd компилятор дает 128 128битных. за них тоже можно вылезти при желании, но разница между ними так же велика, как между жигулями и машиной. на нвидии серьезный кернел не напишешь - регистры быстро кончатся. использование shared дает банк конфликты, а global это вообще дохлый номер. и они сейчас в серьезных аутсайдерах в этом плане.
а гемор с синхронизацией внутри условий для меня лично забил последний гвоздь в гроб куды.
с учетом того что у нвидии нет x86 ядра, праздник гетерогенных процов пройдет мимо них, слышны уже покаркивания кладбищенских ворон и, если нвидия продолжит в том же духе, травя байки про терафлопсы для бабулек у подьездов, то вполне возможно мы будем через несколько лет с ностальгией вспоминать GeForce, как когда-то Voodoo.
Ларрик
Цитата(Nox Metus @ 24.04.2011, 16:48) *
Цитата(joyrider @ 21.04.2011, 22:09) *
Имеем 8 (float Single Precision) операций за такт на ядро x 4 ядра х 3ГГц = 96 Гфлопс
Это с каких таких пор производительность от количества ядер стала возрастать линейно?

А я почему-то думал что "работают" 3 а одно управляет, я ошибаюсь?
__kot2
Цитата(Ларрик @ 24.04.2011, 15:56) *
Цитата(Nox Metus @ 24.04.2011, 16:48) *
Цитата(joyrider @ 21.04.2011, 22:09) *
Имеем 8 (float Single Precision) операций за такт на ядро x 4 ядра х 3ГГц = 96 Гфлопс
Это с каких таких пор производительность от количества ядер стала возрастать линейно?

А я почему-то думал что "работают" 3 а одно управляет, я ошибаюсь?

все работают.
меня тоже так удивляет эти разговор про гигафлопсы. помню, мы в детском садике так спорили какая машина быстрее - у которой 4 колеса, 6 или 8 колес. вот пиковая производительность из той же серии. ближе всего к ядрам обычного проца это мультипроцы или compute unit ы, коих в тесле 14 чтоли, а в5870 20 штук. вот тут уже ближе их можно сравнивать как 4 ядерный проц и как 20ядерный. но с учетом практически отсутствия кэша у этих ядер и того факта что для загрузки этих 20 ядер нужно порядка 5000 активных потоков, когда для загрузки 4 ядер достаточно 4 потоков соотв-но, загрузить видеокарту и заставить ее считать хотя бы с той же скоростью что и cpu это уже достаточно сложная задача.
busa
Цитата(Nox Metus @ 24.04.2011, 16:48) *
Цитата(joyrider @ 21.04.2011, 22:09) *
Имеем 8 (float Single Precision) операций за такт на ядро x 4 ядра х 3ГГц = 96 Гфлопс
Это с каких таких пор производительность от количества ядер стала возрастать линейно?


ну, вообще говоря, есть класс вычислительных задач, которые хорошо масштабируются (80-95% от пика машины). и именно эти задачи лучше всего ложатся на GPGPU.
__kot2
Цитата(Nox Metus @ 25.04.2011, 15:34) *
Цитата(busa @ 24.04.2011, 22:47) *
ну, вообще говоря, есть класс вычислительных задач, которые хорошо масштабируются (80-95% от пика машины)
Для многоядерного x86 это из области фантастики. Есть, конечно, синтетические примеры, но на практике — это фантастика. Для практических задач производительность гораздо меньше, чем число_ядер * производительность_одного_ядра.

в среднем корень от числа ядер, то есть 100 ядерный комп работает в 3 раз быстрее, чем 10 ядерный, если память однородная. если неоднородная и программа заточена на это, то можно получить больший прирост.
по этой причине кстати, мы очень долго еще не увидим более 10 ядерных не серверных чипов от Intel и AMD
Nemo
Цитата(__kot2 @ 25.04.2011, 15:45) *
Цитата(Nox Metus @ 25.04.2011, 15:34) *
Цитата(busa @ 24.04.2011, 22:47) *
ну, вообще говоря, есть класс вычислительных задач, которые хорошо масштабируются (80-95% от пика машины)
Для многоядерного x86 это из области фантастики. Есть, конечно, синтетические примеры, но на практике — это фантастика. Для практических задач производительность гораздо меньше, чем число_ядер * производительность_одного_ядра.

в среднем корень от числа ядер, то есть 100 ядерный комп работает в 3 раз быстрее, чем 10 ядерный, если память однородная. если неоднородная и программа заточена на это, то можно получить больший прирост.
по этой причине кстати, мы очень долго еще не увидим более 10 ядерных не серверных чипов от Intel и AMD

откуда дровишки? в среднем на каком типе задач?
Linpack растёт почти линейно от числа ядер (настоящих), более точно он порпорционален числу FMA, которое может обработать ядро за такт и скорости обработки этого самого FMA (float multiply and add). Имеено к происзодительности Linpack относятся FLOPSы именно для него проиведённый выше расчёт вполне корректный (только за такт Westmere-EX делает одно сложение и одно умножение, а считается FMA, так что не 8FLOP а 4).

Речь не идёт о производительности на широком спектре задач - никому не придёт в гоолову запускать на NVIDIA XML-парсинг или, ну я не знаю, сложные графовые задачи общего вида: они плохо ложаться на регулярную вычислительную структуру. Речь идёт о конкретной метрике FLOPSaх которые, как я отметил выше, расчитываются на кокретном тесте Linpack с конкретными и известними характеристиками.
busa
Цитата(Nemo @ 25.04.2011, 16:59) *
Linpack растёт почти линейно от числа ядер (настоящих), более точно он порпорционален числу FMA, которое может обработать ядро за такт и скорости обработки этого самого FMA (float multiply and add). Имеено к происзодительности Linpack относятся FLOPSы именно для него проиведённый выше расчёт вполне корректный (только за такт Westmere-EX делает одно сложение и одно умножение, а считается FMA, так что не 8FLOP а 4).


Конечно, этот рост зависит от многих параметров, но вот кластер, который дает 87% эффективности на линпаке: http://top500.org/system/performance/10184. Это довольно много, учитывая тот факт, что память -- распределенная, а линпак подразумевает выполнение LU разложения с выбором ведущего элемента.

__kot2
Цитата(Nemo @ 25.04.2011, 15:59) *
откуда дровишки? в среднем на каком типе задач?

это подробно рассматривается в какой-то классической книжке по параллельному программированию, не могу вспомнить в какой именно.
в общем, если все ядра будут читать-писать в одну и ту же области памяти, то накладные расходы на сериализацию и обработку таких обращений таковы, что эффективность будет расти как корень от числа ядер.
а если же удастся разделить задачу на полностью независимые области данных, кои можно загрузить в некую близкую к ядру память, недоступную другим ядрам (например в Cell такая память есть у каждого ядра, у GPU это регистры и локал соотв-но), только в этом случае можно получить близкий к линейному прирост скорости. С натяжкой можно сказать что у проца это кэш. Если писать так, чтобы одно ядро не вымывало кэш любого другого ядра и одновременно писало-читало в память только одно ядро (ну, может 2-3), то можно получить почти линейный прирост. вот и Linpack скорее всего подобным образом работает.
busa
Цитата(__kot2 @ 25.04.2011, 17:18) *
это подробно рассматривается в какой-то классической книжке по параллельному программированию, не могу вспомнить в какой именно.
в общем, если все ядра будут читать-писать в одну и ту же области памяти, то накладные расходы на сериализацию и обработку таких обращений таковы, что эффективность будет расти как корень от числа ядер.
а если же удастся разделить задачу на полностью независимые области данных, кои можно загрузить в некую близкую к ядру память, недоступную другим ядрам (например в Cell такая память есть у каждого ядра, у GPU это регистры и локал соотв-но), только в этом случае можно получить близкий к линейному прирост скорости. С натяжкой можно сказать что у проца это кэш, если мы не будем обращаться в разные области разными ядрами. вот и прирост Linpack может дать почти линейный, если его задачи за кэш не выходят (ну то есть молотятся прямо в кэше, они могут вполне и стримиться через кэш с таким же успехом).


в линпаке полно зависимостей по данным. по сути дела, линпак -- это LU разложение. там внутре, конечно, есть embarrassingly parallel GEMM, но это далеко не все, что там есть. Кроме того, на кластере есть еще и пересылки (выбор ведущего элемента), что несколько сводит на нет ваше утверждение.

Читать из одной и той же области можно. Запись инвалидирует кэш. Хорошие протоколы когерентности рулят.
__kot2
Цитата(busa @ 25.04.2011, 16:24) *
в линпаке полно зависимостей по данным. по сути дела, линпак -- это LU разложение. там внутре, конечно, есть embarrassingly parallel GEMM, но это далеко не все, что там есть. Кроме того, на кластере есть еще и пересылки (выбор ведущего элемента), что несколько сводит на нет ваше утверждение.

поэтому прирост __почти__ линейный. А часто можно разбить задачи на независимые если считать с оверхэдом, то есть, на пальцах, пересекающиеся данные заново рассчитывать на каждом ядре, чтобы избежать пересылки. оверхэд по вычислениям на GPU раза в два это "нормально".
на GPU все вычисления выполняются блоками тредов по 64 штуки. каждый блок не может передать данные в другой блок и между блоками нельзя синхронизоваться. поэтому хочешь-не хочешь а задача разбивается на полностью независимые куски, каждый из которых молотится в 64 потока. чтобы загрузить GPU близко к 100% нужно иметь от порядка 640 активных блоков.

Цитата(busa @ 25.04.2011, 16:24) *
Читать из одной и той же области можно.

это если архитектура широковещательное чтение поддерживает. GPU - поддерживает. CPU - нет. Немного другой пример - представьте себе, например, что актуальные данные лежат в кэше L1 одного проца (да пусть даже ядра) и другой проц зачитывает их. ой, гемора то сколько по пересылке и синхронизации.
busa
Цитата(Nox Metus @ 25.04.2011, 17:25) *
Цитата(busa @ 25.04.2011, 17:13) *
Конечно, этот рост зависит от многих параметров, но вот кластер, который дает 87% эффективности на линпаке: http://top500.org/system/performance/10184.
Вроде, речь шла о увеличении производительности многоядерных x86 с увеличением числа ядер. При чём тут кластер?

при том, что есть на кластере можно получить 87%, то на NUMA это делается гораздо легче -- ниже latency, выше bandwidth.
joyrider
Цитата(Nox Metus @ 24.04.2011, 15:48) *
Цитата(joyrider @ 21.04.2011, 22:09) *
Имеем 8 (float Single Precision) операций за такт на ядро x 4 ядра х 3ГГц = 96 Гфлопс
Это с каких таких пор производительность от количества ядер стала возрастать линейно?

а что не так?
жду развернутого ответа
joyrider
Цитата(Nemo @ 25.04.2011, 15:59) *
(только за такт Westmere-EX делает одно сложение и одно умножение, а считается FMA, так что не 8FLOP а 4).

не понял что имеется ввиду:
1. FMA это вообще то Fused Multiply+Add и это есть только в Sandy Bridge и MIC
2. В чем проблема в одновременным выполнением раздельных инструкций Multiply и Add на разных портах?
Цитата
Core2 (all current products and Nehalem) doubled peak FP performance by adding 128-bit FP ADD and FP MUL EUs (on different ports working with 1 cycle throughput), with peak FP throughput for vectorized code of 2 64-bit MUL and 2 64-bit ADD per cycle (8 SP or 4 DP FLOPS).

joyrider
Цитата(__kot2 @ 25.04.2011, 16:18) *
С натяжкой можно сказать что у проца это кэш. Если писать так, чтобы одно ядро не вымывало кэш любого другого ядра и одновременно писало-читало в память только одно ядро (ну, может 2-3), то можно получить почти линейный прирост. вот и Linpack скорее всего подобным образом работает.

Вы видимо отстали от жизни, но в Nehalem'ах критически важный КЭШ L2 уже давно не разделяемый. Так что делайте loop-blocking и будет вам счастье и ничего вам "невымоет" из КЭШа smile.gif

А вообще читайте умные статьи, где люди описывают эти проблемы:
Shared Cache Capacity
Non scaling behavior due to oversubscription of a shared cache means that the
cache sharing is resulting in a greater amount of cacheline eviction and subsequent
cacheline reloading. On Intel® Core™2 processors a Last Level Cache (LLC) line miss
is counted by the event L2_LINES_IN.SELF.ANY This event counts LLC misses due to
loads, stores, instruction fetching, software and hardware prefetches. For the two
scenarios being discussed the signatures differ but only in an obvious manner. If the total
work is fixed, then non-contentious parallel execution would result in the total count of
the LLC line misses over the execution period being constant as the number of cores used
is increased. If the work scales with the number of cores then the total count per core
should remain constant as the number of used cores is increased.
In either case it is the
total count and not the rate that is indicative of the nature of the issue.
There are several issues that can cause these counts to not follow the patterns
discussed above. A few are
1) True and false sharing of cachelines causing extra cacheline traffic
2) The working set size distributions’ compatibility to the LLC size is degraded with
multi-core execution, i.e. the parallel processes evict each others’ lines

http://software.intel.com/sites/products/c...non_scaling.pdf
Nemo
Цитата(joyrider @ 25.04.2011, 18:04) *
Цитата(Nemo @ 25.04.2011, 15:59) *
(только за такт Westmere-EX делает одно сложение и одно умножение, а считается FMA, так что не 8FLOP а 4).

не понял что имеется ввиду:
1. FMA это вообще то Fused Multiply+Add и это есть только в Sandy Bridge и MIC
2. В чем проблема в одновременным выполнением раздельных инструкций Multiply и Add на разных портах?
Цитата
Core2 (all current products and Nehalem) doubled peak FP performance by adding 128-bit FP ADD and FP MUL EUs (on different ports working with 1 cycle throughput), with peak FP throughput for vectorized code of 2 64-bit MUL and 2 64-bit ADD per cycle (8 SP or 4 DP FLOPS).


Проблемы нет, просто неправильно считать их за 2 операции: 2 порта вместе делают 1 MADD именно их и считают за операции (это более правильно, чем FMA, я согласен) именно это я и отметил. FMA в AVX нет. (Пруф-линк)
__kot2
Цитата(joyrider @ 25.04.2011, 18:15) *
Цитата(__kot2 @ 25.04.2011, 16:18) *
С натяжкой можно сказать что у проца это кэш. Если писать так, чтобы одно ядро не вымывало кэш любого другого ядра и одновременно писало-читало в память только одно ядро (ну, может 2-3), то можно получить почти линейный прирост. вот и Linpack скорее всего подобным образом работает.

Вы видимо отстали от жизни, но в Nehalem'ах критически важный КЭШ L2 уже давно не разделяемый. Так что делайте loop-blocking и будет вам счастье и ничего вам "невымоет" из КЭШа smile.gif

это зависит от конкретного проца. у AMD, насколько помню, L3 разделяемый, у Core 2 тоже разделяемый. к тому же неразделяемый кэш решает малую долю проблем.
joyrider
Цитата(Nemo @ 25.04.2011, 21:49) *
Цитата(joyrider @ 25.04.2011, 18:04) *
Цитата(Nemo @ 25.04.2011, 15:59) *
(только за такт Westmere-EX делает одно сложение и одно умножение, а считается FMA, так что не 8FLOP а 4).

не понял что имеется ввиду:
1. FMA это вообще то Fused Multiply+Add и это есть только в Sandy Bridge и MIC
2. В чем проблема в одновременным выполнением раздельных инструкций Multiply и Add на разных портах?
Цитата
Core2 (all current products and Nehalem) doubled peak FP performance by adding 128-bit FP ADD and FP MUL EUs (on different ports working with 1 cycle throughput), with peak FP throughput for vectorized code of 2 64-bit MUL and 2 64-bit ADD per cycle (8 SP or 4 DP FLOPS).


Проблемы нет, просто неправильно считать их за 2 операции: 2 порта вместе делают 1 MADD именно их и считают за операции (это более правильно, чем FMA, я согласен) именно это я и отметил. FMA в AVX нет. (Пруф-линк)


Я извиняюсь, но я не въезжаю
Открываем Intel® 64 and IA-32 Architectures Optimization Reference Manual (Order Number: 248966-024 April 2011)
Согласно этой таблице что мне мешает одновременно выполнять две разные векторные single float микрооперации умножение и сложения на порте 0 и 5? Не вижу ошибки в моих расчетах.

P.S. за пруфлинк спасибо. не знал что FMA выкинули из SandyBridge. исходное сообщение подправил
joyrider
О пересылки данных или когда выгодно считать на CUDA.

Открываем документ «CUDA C Best Practices Guide» (у меня версия от 8/20/2010) и читаем раздел «What Runs on a CUDA-Enabled Device?»

Цитата
To use CUDA, data values must be transferred from the host to the device along the PCI Express (PCIe) bus. These transfers are costly in terms of performance and should be minimized. This cost has several ramifications:
The complexity of operations should justify the cost of moving data to and from the device. Code that transfers data for brief use by a small number of threads will see little or no performance benefit. The ideal scenario is one in which many threads perform a substantial amount of work.
For example, transferring two matrices to the device to perform a matrix addition and then transferring the results back to the host will not realize much performance benefit. The issue here is the number of operations performed per data element transferred. For the preceding procedure, assuming matrices of size NЧN, there are N**2 operations (additions) and 3N**2 elements transferred, so the ratio of operations to elements transferred is 1:3 or O(1). Performance benefits can be more readily achieved when this ratio is higher. For example, a matrix multiplication of the same matrices requires N**3 operations (multiply-add), so the ratio of operations to elements transferred is O(N), in which case the larger the matrix the greater the performance benefit. The types of operations are an additional factor, as additions have different complexity profiles than, for example, trigonometric functions. It is important to include the overhead of transferring data to and from the device in determining whether operations should be performed on the host or on the device.


Другими словами, вычисления должны оправдывать пересылку данных. Сложность вычисления над одним элементом матрицы должна быть достаточно высокой.

А когда это происходит?

Рассмотрим вариант с синхронной передачей данных (с асинхронной передачей и гетерогенные вычисления рассмотрим позже). Это такой вид передачи, когда мы закинули данные на карту и ничего не делаем пока не получим результат. Допустим, у нас есть две матрицы и мы хотим сделать что-то очень сложное с ними, причем на столько сложное, что пока мы считаем текущую КЭШ линию, последующая успевает подойти к нам из RAM благодаря:
  • hardware prefetcher’ам (при выполнении на CPU) или умело расставленным prefetch инструкциям (при выполнении на карте)
  • и умелому использованию таких техник оптимизации кода как loop-blocking

т.е. для нас не являются проблемами:
  • шина памяти
  • пинг-понг КЭШ линеек из-за false-sharing
  • излишняя синхронизация
  • дисбаланс нагрузки между ядрами
  • вытеснение нужных данных из shared КЭШа (для CPU)
  • невыравненность данных и прочая лабуда


В результате чего мы имеем практически идеальную масштабируемость которая позволяет работать практически на пике производительности (как бы в это не хотели верить некоторые здесь «спецы»)

Для того, чтобы вычисление такого кода на карте оправдывалось нам нужно соблюдение условия:
Код
T(cpu) > T(transfer) + T(cuda)

T(cpu) время выполнения вычислений на CPU
T(transfer) время пересылки данных
T(cuda) время выполнения вычислений на карте

В первом моем посте я показал, что вычисления на CUDA C2050 могут быть быстрее вычислений на Nehalem максимум в 10 раз.
Подставим это в формулу:
Код
T(cpu) > T(transfer) + 1/10 T(cpu)
9/10 T(cpu) > T(transfer)

Допустим, время пересылки включает в себя пересылку двух матриц (1.5Gb+1.5Gb) на карту и скачивание результата в виде одной матрицы (1.5Gb) обратно. Для этого нам нужно прокачать 4.5Gb через PCI x16 со скоростью 8Gb/сек. На это нам потребуется 0.56 сек. Т.е.
Код
9/10 T(cpu) > 0.56 сек, T(cpu) > 0.63 сек

Если сложность вычислений для приведенных выше двух матриц высокая и время на их обработку больше 0.63 сек, то вычисления на карте оправдают перекачку данных. Если же нужно обработать несколько пар таких матриц и обработка этих пар занимает несколько часов на CPU, то нужно брать в расчет время вычисления одной пары при условии что используется только синхронная передача данных.
joyrider
Продолжаем наши заумные разговоры об HPC.

Недавно на глаза мне попалась интересная статейка, написанная инженерами Intel. Статья
называется забавно «Debunking the 100X GPU vs. CPU myth: an evaluation of throughput computing on CPU and GPU». Или если по-русски, то переводится как «развенчание мифа о 100кратном превосходстве GPU над CPU: оценка высокопроизводительных вычислений на CPU и GPU». Статья написана максимально объективно, по-честному, без какой-либо предвзятости. Я прикрепил файл для тех кому интересно.
Суть статьи следующая: инженеры Intel решили проверить насколько основательными являются заявления о том, что NVIDIA GPU во много раз быстрее Intel CPU. Для этого они просмотрели все заявления в которых утверждалось, что NVIDIA дает прирост от 10 до 1000 раз по сравнению с CPU и собрали все приложения на которых была получена такая умопомрачительная разница. Затем, инженеры изучили собранные приложения и соптимизировали их для ОБОИХ платформ. Для некоторых приложений они взяли наилучшие реализации с сайта NVIDIA. После этого они запустили приложения на NVIDIA GTX280 и получили цифры такие же, а кое где и лучше чем официально опубликованные и пояснили, каким образом они смогли лучшие цифры, показывая свой профессионализм даже в железе NVIDIA. После чего они запустили те же приложения на Intel i7-960 и получили разницу в среднем в 2.5 раза меньше по сравнению с NVIDIA.
Нужно отметить, что для железа NVIDIA учитывалось только чистое время выполнения. Пересылка данных по шине PCI не учитывалась (которая может свести на нет всю выгоду от использования NVIDIA). Т.е. Intel еще и дал фору NVIDIA, что еще раз говорит об отсутствие предвзятости.
Далее, инженеры Intel подробно описали, что хорошо, а что плохо с точки зрения архитектурных особенностей для каждого приложения. Например, GJK быстрее в 14 раз на NVIDIA за счёт texture sampler, а вот Sort и Search жутко тормозили на NVIDIA за счёт маленького объема КЭШ.
Потом в статье идет вывод, в котором поясняется, что нечестно сравнивать оптимизированный код под NVIDIA с неоптимизированным кодом для CPU (как я уже писал) и получать разницу в 1000 раз. И так же нечестно сравнивать высокопроизводительную карту с мобильным процессором, на котором была получена такая нехилая разница, так как в мобильном процессоре зарублена производительность в угоду низкому энергопотреблению.

Еще раз замечу, что я не хочу говорить о таких метриках как FLOPS/WATT и $/FLOPS.


Теперь пару слов о моем первом посте, где я сказал что максимальная разница между CPU и GPU не может быть больше чем в 10 раз. Дело в том, что это утверждение справедливо если сравнение идет при прочих равных. (Интересно и почему меня никто не поправил здесь?) Однако в статье приводится пример где разница была в 15 раз. Дело в том, что инженеры Intel использовали фиксированное устройство «texture sampling unit» на NVIDIA. Имея такое устройство некоторые задачи можно выполнять быстрее в разы. Единственная проблема заключается в том, что это устройство умеет выполнять только одну единственную задачу, которую имеют далеко не все алгоритмы.
__kot2
Цитата(joyrider @ 26.05.2011, 18:31) *
называется забавно «Debunking the 100X GPU vs. CPU myth: an evaluation of throughput computing on CPU and GPU». Или если по-русски, то переводится как «развенчание мифа о 100кратном превосходстве GPU над CPU: оценка высокопроизводительных вычислений на CPU и GPU». Статья написана максимально объективно, по-честному, без какой-либо предвзятости. Я прикрепил файл для тех кому интересно.

ну да, 100кратное превосходство это конечно бабулькины росказни. но надо на потенциал и на разницу в скорости роста и понятно становится, что будущее HPC это GPGPU
как я уже говорил, у Нвидии вообще хреновая архитектура, они скорее всего ее уже в панике перепиливают.
anpol
Цитата(__kot2 @ 28.05.2011, 21:01) *
ну да, 100кратное превосходство это конечно бабулькины росказни. но надо на потенциал и на разницу в скорости роста и понятно становится, что будущее HPC это GPGPU
как я уже говорил, у Нвидии вообще хреновая архитектура, они скорее всего ее уже в панике перепиливают.

нихрена непонил накаком языке выпишите.,? читайте хоть сначала прежде чем других заставлять это читать
__kot2
Цитата(anpol @ 28.05.2011, 23:37) *
Цитата(__kot2 @ 28.05.2011, 21:01) *
ну да, 100кратное превосходство это конечно бабулькины росказни. но надо на потенциал и на разницу в скорости роста и понятно становится, что будущее HPC это GPGPU
как я уже говорил, у Нвидии вообще хреновая архитектура, они скорее всего ее уже в панике перепиливают.

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

сам низнаю. потсаны притощили йозыг, йананем пешу


Цитата(Nox Metus @ 29.05.2011, 0:43) *
Цитата(__kot2 @ 28.05.2011, 22:01) *
у Нвидии вообще хреновая архитектура
Какая именно? Железа, драйверов, cuda?

любая современная железа. в смысле Fermi тоже гавно. в чем выражается? я уже писал - элементарно регистров не хватает + хронические проблемы с дивергент бранчами и синхронизацией, ничего не напишешь там серьезного.
некоторые возмутятся - да моя Нвидия 580ая порвет в играх твой Радеон ...
ну дык графические шейдеры они же примитивные до ужаса, там нвидии хватает за глаза. вычислительные гораздо сложнее обычно.
joyrider
Цитата(__kot2 @ 28.05.2011, 21:01) *
Цитата(joyrider @ 26.05.2011, 18:31) *
называется забавно «Debunking the 100X GPU vs. CPU myth: an evaluation of throughput computing on CPU and GPU». Или если по-русски, то переводится как «развенчание мифа о 100кратном превосходстве GPU над CPU: оценка высокопроизводительных вычислений на CPU и GPU». Статья написана максимально объективно, по-честному, без какой-либо предвзятости. Я прикрепил файл для тех кому интересно.

как я уже говорил, у Нвидии вообще хреновая архитектура, они скорее всего ее уже в панике перепиливают.

Прочитав статью мне стало понятно, что у любой архитектуры есть свои плюсы и минусы. Но, примечательно что для SGEMM на GTX280 не была достигнута в силу каких-то архитектуных ограничений. The reason for not achieving the peak compute ratio is because GPUs do not achieve peak efficiency in the presence of shared buffer accesses. Я считаю это серьезным недостатком.

А как Вам архитектура MIC от Intel? smile.gif
__kot2
Цитата(joyrider @ 29.05.2011, 10:21) *
А как Вам архитектура MIC от Intel? smile.gif

пиковое TDP процов 130 ватт
TDP карт 5870 - 180вт, 6970 320 ватт. nvidia 580 вообще трехслотовая и имеет tdp в 250 ватт.
если Интел будет пытаться сделать убийцу GPGPU на tdp 130 ватт, у них ничего не выйдет. гетерогенные процы сейчас выглядят очень слабо. например, LLano из себя представляет четвертинку от 5870 с соотвующей скоростью (я замерял), а sandy bridge только видео кодировать и умеет, графически он очень слаб. да и даже в кодировании видео его могут скоро разорвать GPGPUшные энкодеры.

я думаю в ближайшее время ни у кого не получится сделать крутой гетерогенный проц. Интел уже сделали реально здоровые процы, скажем 24 или 48ядерные с гигантским tdp скорее всего, но получили себестоимость бешеную, скорее всего на уровне x6 от их топовых i7, ну и смекнули что процы по 6 штук баксов брать мало кто будет. они скорее всего не хотят также увеличивать tdp до ватт 300от на проц, не знаю почему, может типа зеленые, борьба с энергопотреблением и все такое.
так что от них я чуда не жду. чуда я жду от амдшников, когда они увеличат еще в два раза кол-во регистров, увеличат раз в 5 скорость трансферов на какой-нить pci-e x128 и кол-во compute units еще раза в 4. вот это будет тема. tdp конечно у такого монстра на даже техпроцессе скажем 22 нанометра будет ватт 500
joyrider
Цитата(__kot2 @ 29.05.2011, 11:29) *
Цитата(joyrider @ 29.05.2011, 10:21) *
А как Вам архитектура MIC от Intel? smile.gif

пиковое TDP процов 130 ватт
TDP карт 5870 - 180вт, 6970 320 ватт. nvidia 580 вообще трехслотовая и имеет tdp в 250 ватт.
если Интел будет пытаться сделать убийцу GPGPU на tdp 130 ватт, у них ничего не выйдет. гетерогенные процы сейчас выглядят очень слабо. например, LLano из себя представляет четвертинку от 5870 с соотвующей скоростью (я замерял), а sandy bridge только видео кодировать и умеет, графически он очень слаб. да и даже в кодировании видео его могут скоро разорвать GPGPUшные энкодеры.

Я вроде бы спросил про MIC smile.gif а это не гетерогенный процессор

Цитата(__kot2 @ 29.05.2011, 11:29) *
Интел уже сделали реально здоровые процы, скажем 24 или 48ядерные с гигантским tdp скорее всего, но получили себестоимость бешеную, скорее всего на уровне x6 от их топовых i7, ну и смекнули что процы по 6 штук баксов брать мало кто будет. они скорее всего не хотят также увеличивать tdp до ватт 300от на проц, не знаю почему, может типа зеленые, борьба с энергопотреблением и все такое.

Это просто ваши домыслы или вы откуда то всё это взяли?

Лично мне MIC нравится тем, что код для него не потребует каких либо существенных изменений. Т.е. Intel предлагает продолжать писать в том же стиле, в котором мы пишем для обычных многоядерных процессоров и использовать одни и те же исходники для работы на MIC и Intel ® 64.
Вот здесь есть пример http://www.intel.com/technology/architectu...n/mic/index.htm
Standard programming models
A key advantage for developers using Intel MIC products is the ability to use standard, existing programming tools and methods. Intel MIC architecture combines many Intel CPU cores onto a single chip. These cores can be programmed using standard C, C++, and FORTRAN source code. The same program source code written for Intel Many Integrated Core products can be compiled and run on a standard Intel Xeon processor. The familiar programming model removes developer training barriers allowing the developer to focus on the problems rather than software engineering.

For example, CERN OpenLab, the European Organization for Nuclear Research, was able to use the Knights Ferry kit to migrate a complex benchmark written in C++ code to the new architecture in just a few days. According to Sverre Jarp, CTO of the CERN open lab, "The familiar hardware programming model allowed us to get the software running much faster than expected."
__kot2
Цитата(joyrider @ 29.05.2011, 20:21) *
Я вроде бы спросил про MIC smile.gif а это не гетерогенный процессор

а как они тогда заставят его работать?
негетерогенный это в переводе на русский однородный. то бишь каждое ядро может связаться с любым другим за одно и то же время.
чтобы так связать 80 ядер нужно связать каждое с каждым. каждое с 80ю другими. а какова сложность контроллера будет! это же капец! нифига работать не будет.
они могут сэмулировать это, связав все-таки не все со всеми, а попроще, но для написания HPC суперпрог потребуется знание геометрии соединения все равно.

добавил -
википедия говорит что
Цитата
Along with 80 cores, the chip also contains 80 routers. Each core has a dedicated router which is responsible for the communication of that core with all other cores and components of the processor. The router uses a five port system with 1 port going to each of the surrounding cores and one going to the DRAM (the processors local memory). The chip is laid out in an 8 core by 10 core format. Each of the 8 cores in any of the 10 rows, called nodes, has the ability to communicate directly with other cores within the same node. Communication between nodes and to other processor components is directed through a routing system

то бишь он гетерогенный - пачками по 8 процы обьединены. но это достаточно хорошо может быть скрыто, так что может и проц неплохой на самом деле.

Цитата(joyrider @ 29.05.2011, 20:21) *
Лично мне MIC нравится тем, что код для него не потребует каких либо существенных изменений. Т.е. Intel предлагает продолжать писать в том же стиле, в котором мы пишем для обычных многоядерных процессоров и использовать одни и те же исходники для работы на MIC и Intel ® 64.

то есть будет "то же самое", но вместо 8 потоков (4 ядра с HT) будет 80. замечательно. цена и tdp я так предполагаю возрастают пропорционально? хотя в википедении честно-честно указывается нормальное tdp, но с учетом того, что вероятнсть сделать кристалл с 80ядрами сильно меньше вероятности сделать 16 4ядерных + аццкий контроллер памяти, цена может быть ого-го.

вообще, конечно я за новые много-много ядерные процы, надоели уже 4ех smile.gif
joyrider
Цитата(__kot2 @ 29.05.2011, 21:17) *
то есть будет "то же самое", но вместо 8 потоков (4 ядра с HT) будет 80. замечательно. цена и tdp я так предполагаю возрастают пропорционально? хотя в википедении честно-честно указывается нормальное tdp, но с учетом того, что вероятнсть сделать кристалл с 80ядрами сильно меньше вероятности сделать 16 4ядерных + аццкий контроллер памяти, цена может быть ого-го.

вообще, конечно я за новые много-много ядерные процы, надоели уже 4ех smile.gif

Ну там не 80. В том чипе, который Intel собирается выводить на рынок будет 50 ядер. TDP возрастать пропорционально не будут, так как ядро MIC это ядро P54C (Pentium I). Оно имеет очень низкое потребление за счет отсутствия технологии out-of-order. Поэтому 50 таких ядер, наштампованых по 22нм процессу врядли будут потреблять больше чем самый крутой Intel Core i7 в серверном варианте.
Nemo
Цитата(joyrider @ 30.05.2011, 8:57) *
Цитата(__kot2 @ 29.05.2011, 21:17) *
то есть будет "то же самое", но вместо 8 потоков (4 ядра с HT) будет 80. замечательно. цена и tdp я так предполагаю возрастают пропорционально? хотя в википедении честно-честно указывается нормальное tdp, но с учетом того, что вероятнсть сделать кристалл с 80ядрами сильно меньше вероятности сделать 16 4ядерных + аццкий контроллер памяти, цена может быть ого-го.

вообще, конечно я за новые много-много ядерные процы, надоели уже 4ех smile.gif

Ну там не 80. В том чипе, который Intel собирается выводить на рынок будет 50 ядер. TDP возрастать пропорционально не будут, так как ядро MIC это ядро P54C (Pentium I). Оно имеет очень низкое потребление за счет отсутствия технологии out-of-order. Поэтому 50 таких ядер, наштампованых по 22нм процессу врядли будут потреблять больше чем самый крутой Intel Core i7 в серверном варианте.

Откуда дровишки?
Nemo
Цитата(__kot2 @ 29.05.2011, 21:17) *
Цитата
Along with 80 cores, the chip also contains 80 routers. Each core has a dedicated router which is responsible for the communication of that core with all other cores and components of the processor. The router uses a five port system with 1 port going to each of the surrounding cores and one going to the DRAM (the processors local memory). The chip is laid out in an 8 core by 10 core format. Each of the 8 cores in any of the 10 rows, called nodes, has the ability to communicate directly with other cores within the same node. Communication between nodes and to other processor components is directed through a routing system

то бишь он гетерогенный - пачками по 8 процы обьединены. но это достаточно хорошо может быть скрыто, так что может и проц неплохой на самом деле.

Это не о MIC. В MIC (судя по открытым источникам) кольцевая шина как в Sandy Bridge.

А вообще разговаривал тут как-то про перспективы MIC. Даже в теории Fermi он не догоняет даже с 48ю ядрами, однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД. И весь вопрос в том, сможет ли он обойти это железо на столько, чтобы под него стали переписывать софт, ибо хоть программная модель и далеко не CUDA кое-что допиливать и перептсывать придётся. И если по некоторым исследованиям 20% прироста поизводительности это минимум, ради которого в больших проектах меняют опции компиляции, 50% - компилятор, то не ясно какой должен быть выигрыш, чтобы взялись за переписывание кода.
__kot2
Цитата(joyrider @ 30.05.2011, 8:57) *
Цитата(__kot2 @ 29.05.2011, 21:17) *
то есть будет "то же самое", но вместо 8 потоков (4 ядра с HT) будет 80. замечательно. цена и tdp я так предполагаю возрастают пропорционально? хотя в википедении честно-честно указывается нормальное tdp, но с учетом того, что вероятнсть сделать кристалл с 80ядрами сильно меньше вероятности сделать 16 4ядерных + аццкий контроллер памяти, цена может быть ого-го.

вообще, конечно я за новые много-много ядерные процы, надоели уже 4ех smile.gif

Ну там не 80. В том чипе, который Intel собирается выводить на рынок будет 50 ядер. TDP возрастать пропорционально не будут, так как ядро MIC это ядро P54C (Pentium I). Оно имеет очень низкое потребление за счет отсутствия технологии out-of-order. Поэтому 50 таких ядер, наштампованых по 22нм процессу врядли будут потреблять больше чем самый крутой Intel Core i7 в серверном варианте.

это было бы супер. но есть ньюанс.
проц и видеокарта проводит море времени в ожидании данных. обычно кэш хит у видеокарт что-то около 2-3 процентов. и от кэша там толку никакого. кэш это обман программиста, нужный для того, чтобы тот думал, что память имеет маленькую латентность. никто же не скрывает что одно чтение на видеокарте нужно ждать 500 тактов. а проц это старается скрыть. пока это ему удается за счет большого обьема кэша, который в моем представлении и содержит больше половины всех транзисторов процессора. а скорее вообще процентов 80. кэш нужен каждому ядру. если ядер 50 то нам нужно для поддержания обмана зрения программиста хотя бы по мегабайту кэша на ядро, а tdp транзисторов этих кэшей будет гигантском.
соотв-но, большого кэша у ядер MIC не будет. будет наверное килобайт 128 на ядро. а для современных программ это очень мало.


Цитата(Nemo @ 30.05.2011, 9:27) *
Это не о MIC. В MIC (судя по открытым источникам) кольцевая шина как в Sandy Bridge.

это не подходит для большого числа ядер

Цитата(Nemo @ 30.05.2011, 9:27) *
А вообще разговаривал тут как-то про перспективы MIC. Даже в теории Fermi он не догоняет даже с 48ю ядрами, однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД. И весь вопрос в том, сможет ли он обойти это железо на столько, чтобы под него стали переписывать софт, ибо хоть программная модель и далеко не CUDA кое-что допиливать и перептсывать придётся. И если по некоторым исследованиям 20% прироста поизводительности это минимум, ради которого в больших проектах меняют опции компиляции, 50% - компилятор, то не ясно какой должен быть выигрыш, чтобы взялись за переписывание кода.

все HPC штуки гетерогенные, все отличают время пересылки данных между разными ядрами внутри одного проца, между кэшем и памятью, между разными процами на одной материнке и между разными узлами.
я не думаю, что интелу удастся продолжить обманывать программистов насчет гетерогенности памяти. раньше это удавалось кэшем. сейчас возможно удастся быстрой шиной. но быстрых шин я не знаю. бывают шины широкие, они все отличаются большой латентностью, значит данные нужно передавать большими пачками
joyrider
Цитата(Nemo @ 30.05.2011, 9:19) *
Цитата(joyrider @ 30.05.2011, 8:57) *
Цитата(__kot2 @ 29.05.2011, 21:17) *
то есть будет "то же самое", но вместо 8 потоков (4 ядра с HT) будет 80. замечательно. цена и tdp я так предполагаю возрастают пропорционально? хотя в википедении честно-честно указывается нормальное tdp, но с учетом того, что вероятнсть сделать кристалл с 80ядрами сильно меньше вероятности сделать 16 4ядерных + аццкий контроллер памяти, цена может быть ого-го.

вообще, конечно я за новые много-много ядерные процы, надоели уже 4ех smile.gif

Ну там не 80. В том чипе, который Intel собирается выводить на рынок будет 50 ядер. TDP возрастать пропорционально не будут, так как ядро MIC это ядро P54C (Pentium I). Оно имеет очень низкое потребление за счет отсутствия технологии out-of-order. Поэтому 50 таких ядер, наштампованых по 22нм процессу врядли будут потреблять больше чем самый крутой Intel Core i7 в серверном варианте.

Откуда дровишки?

Пожалуйста:
http://www.intel.com/pressroom/archive/rel...0100531comp.htm
Targeting high-performance computing segments such as exploration, scientific research and financial or climate simulation, the first product, codenamed "Knights Corner," will be made on Intel's 22-nanometer manufacturing (nm) process – using transistor structures as small as 22 billionths of a meter – and will use Moore's Law to scale to more than 50 Intel processing cores on a single chip.
http://hpc.mipt.ru/index.php?option=com_co...emid=78&lang=ru
Несложно догадаться, откуда взялась архитектура MIC и процессор Knights Corner. Не делает из этого секрета и Intel, прямо указывая на то, что архитектура «унаследована у нескольких проектов Intel, включая Larrabee». Другими словами, неудачная попытка затмить всех и вся на рынке дискретных графических решений завершена. Многоядерный Pentium P54C получает второй шанс. На этот раз Intel попробует применить его в суперкомпьютерах.
joyrider
Цитата(Nemo @ 30.05.2011, 9:27) *
Даже в теории Fermi он не догоняет даже с 48ю ядрами,

Вот здесь вот поподробнее пожалуйста. Характеристики Fermi и MIC.

Цитата(Nemo @ 30.05.2011, 9:27) *
однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД.

Это как это? MIC такая же карта как и Fermi и для того, чтобы на ней считать, нужно закачивать на нее данные и код и учитывать время закачки, которое должно быть меньше времени исполнения самой программы на карте.
Более того MIC построен на in-order архитектуре P54C, а это никогда не будет конурентом многоядерного out-of-order железа от Интел и АМД, так как изначально задачи у них разные

Цитата(Nemo @ 30.05.2011, 9:27) *
И весь вопрос в том, сможет ли он обойти это железо на столько, чтобы под него стали переписывать софт, ибо хоть программная модель и далеко не CUDA кое-что допиливать и перептсывать придётся. И если по некоторым исследованиям 20% прироста поизводительности это минимум, ради которого в больших проектах меняют опции компиляции, 50% - компилятор, то не ясно какой должен быть выигрыш, чтобы взялись за переписывание кода.

А вот эти проценты вы откуда взяли?
Более того, почему люди всё-таки беруться переписывать код для CUDA не зная о возможном приросте в производительности, а для MIC не возьмуться?
joyrider
Цитата(__kot2 @ 30.05.2011, 10:07) *
соотв-но, большого кэша у ядер MIC не будет. будет наверное килобайт 128 на ядро. а для современных программ это очень мало.

Судя вот по этой ссылке у MIC будет нечто похожее
http://www.anandtech.com/show/2580/7
L1 Cache Size 32KB
L2 Cache Size 256KB
Это мало или много? smile.gif
__kot2
Цитата(joyrider @ 30.05.2011, 10:27) *
Цитата(__kot2 @ 30.05.2011, 10:07) *
соотв-но, большого кэша у ядер MIC не будет. будет наверное килобайт 128 на ядро. а для современных программ это очень мало.

Судя вот по этой ссылке у MIC будет нечто похожее
http://www.anandtech.com/show/2580/7
L1 Cache Size 32KB
L2 Cache Size 256KB
Это мало или много? smile.gif

это совпадает в общем-то с кол-вом памяти на compute unit у 5870. ну, это не много точно, но вполне достаточно для многих задач. так что наверное неплохой проц вырисовывается. только цена и дата выпуска все еще непонятна.
но мне кажется что если просто взять этот суперпроц и просто запустить на нем какую-нибудь современную игрушку (только неграфическую часть), то она на нем будет тормозить. современные обычные программы ориентированы на большие кэши, мегабайт от 4, на несколько тяжелых основных потоков, обычно не более 2ух и на несколько временных легких потоков, которые достаточно быстро завершаются и вообще часто бездействуют.
если пытаться на нем выполнить еще и графику, тормозить будет очень сильно.
Nemo
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
Даже в теории Fermi он не догоняет даже с 48ю ядрами,

Вот здесь вот поподробнее пожалуйста. Характеристики Fermi и MIC.

За Fermi возьмём GF580 - топовая одночиповая видеокарта Nvidia на данный момент. Топовая производительность 1581.1GFlops (FMA). [по данным википедии]. Производительность MIC легко посчитать, скажем, для 2GHz, по статье на Ананде, на которую уже ссылались. Одно ядро делает 16 SP операций за такт, умножаем на 50 ядер, на 2GHz - примерно 1600GFlops в будущем, а у NVidia столько уже сейчас.
Nemo
Цитата(__kot2 @ 30.05.2011, 10:07) *
Цитата(Nemo @ 30.05.2011, 9:27) *
Это не о MIC. В MIC (судя по открытым источникам) кольцевая шина как в Sandy Bridge.

это не подходит для большого числа ядер

Об этом написано в упомянутой вами статье у Ананда.
Nemo
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД.

Это как это? MIC такая же карта как и Fermi и для того, чтобы на ней считать, нужно закачивать на нее данные и код и учитывать время закачки, которое должно быть меньше времени исполнения самой программы на карте.
Более того MIC построен на in-order архитектуре P54C, а это никогда не будет конурентом многоядерного out-of-order железа от Интел и АМД, так как изначально задачи у них разные

Да ну...
Суперкомпьютеры (а именно туда собирается MIC) уже сейчас строятся как на OOO-железе от Intel и AMD, так и на карточках NVidia. И задачи они решают совершенно одинаковые - прогноз погоды, физическое моделирование, биоинформатика и т.п. Так что конкурировать он будет именно с ними: грубо говоря, при покупке нового суперкомпьютера вопрос будет стоять ставить кучу Xeon и пускать существующий код, кучу MIC и несколько изменить код или кучу Tesla и переписать приложение под CUDA.

Ну а про програмную модель - это был в частности и ваш тезис. Переписывание под CUDA и под MIC - это две большие разницы, ибо MIC всё-таки не шейдерное железо с кучей ограничений, а практически обычное ядро. Затраты на пересылку данных действительно существуют и там и там, но как раз они более-менее скрыты от программиста (ну точнее это не самое сложное в переписывании), сложнее изменить алгоритм, чтобы удовлетворить все требованния на CUDA Kernels, а MIC этого требовать не будет.
joyrider
Цитата(Nemo @ 30.05.2011, 17:41) *
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
Даже в теории Fermi он не догоняет даже с 48ю ядрами,

Вот здесь вот поподробнее пожалуйста. Характеристики Fermi и MIC.

За Fermi возьмём GF580 - топовая одночиповая видеокарта Nvidia на данный момент. Топовая производительность 1581.1GFlops (FMA). [по данным википедии]. Производительность MIC легко посчитать, скажем, для 2GHz, по статье на Ананде, на которую уже ссылались. Одно ядро делает 16 SP операций за такт, умножаем на 50 ядер, на 2GHz - примерно 1600GFlops в будущем, а у NVidia столько уже сейчас.

Секундочку,
Давайте по порядку. Длина вектора MIC 512 бит, т.е. 64 байта или 16 single float. Я думаю, что векторная архитектура MIC будет уметь делать FMA, так как эту операцию хотели воткнуть даже в AVX Sandy Bridge. А вот про 2GHz я что-то не уверен. Скорее всего будет что-то типа 1.4GHz. При таких параметрах получаем 2.2GFLOPS.
К тому моменту, когда MIC выйдет на рынок я думаю NVIDIA предложит что-то похожее по производительности ну или не на много выше. Опять же Intel делает акцент не на производительность, а на удобство использования. Поэтому, железо которое будет на 5-10% медленнее чем конкуренты всё равно будет востребованным, если процесс портирования софта под него будет безболезненным.
joyrider
Цитата(Nemo @ 30.05.2011, 17:50) *
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД.

Это как это? MIC такая же карта как и Fermi и для того, чтобы на ней считать, нужно закачивать на нее данные и код и учитывать время закачки, которое должно быть меньше времени исполнения самой программы на карте.
Более того MIC построен на in-order архитектуре P54C, а это никогда не будет конурентом многоядерного out-of-order железа от Интел и АМД, так как изначально задачи у них разные

Да ну...
Суперкомпьютеры (а именно туда собирается MIC) уже сейчас строятся как на OOO-железе от Intel и AMD, так и на карточках NVidia. И задачи они решают совершенно одинаковые - прогноз погоды, физическое моделирование, биоинформатика и т.п. Так что конкурировать он будет именно с ними: грубо говоря, при покупке нового суперкомпьютера вопрос будет стоять ставить кучу Xeon и пускать существующий код, кучу MIC и несколько изменить код или кучу Tesla и переписать приложение под CUDA.

Давайте не будем всё сваливать в одну кучу. Есть разные задачи и они по разному выполняются на различных архитектурах. Это факт. Что-то быстрее идет на CUDA чем на Intel ® 64, а что-то и наоборот. Иначе все бы уже давно перешли на железо CUDA smile.gif Но уже сейчас не стоит вопрос о том, что ставить. Все ставят Intel или AMD, а для высокопроизводительных вычислений дополнительно ставят железо от NVIDIA, хотя бы потому, что метрика FLOPS/WATT всяко лучше у последнего. Взгляните на http://www.top500.org/. Поэтому MIC будет конкурировать именно с NVIDIA.

Цитата(Nemo @ 30.05.2011, 9:27) *
Затраты на пересылку данных действительно существуют и там и там, но как раз они более-менее скрыты от программиста (ну точнее это не самое сложное в переписывании), сложнее изменить алгоритм, чтобы удовлетворить все требованния на CUDA Kernels, а MIC этого требовать не будет.

А вот позвольте не согласиться. Пересылка данных это удовольствие дорогое. Я вам советую почитать что такое асинхронная передача данных в документе "CUDA C Best Practices Guide", раздел "Asynchronous Transfers and Overlapping Transfers with Computation". Если в вашем алгоритме невозможна такая передача, (т.е. вы не можете отправлять последующую порцию данных в тот момент пока вычисляется предыдущая) то PCI шина для вас может стать барьером и выгоднее будет считать на CPU.
sorry за орфографические ошибки, у меня на этом компе не стоит лицензионный офис
__kot2
на самом деле да, есть задачи, которые на видеокарты очень плохо кладутся. например, zip-компрессия.
фючер будет таковым, что часть задачи будет решаться на CPU, часть на GPU, а часть на этом http://www.dwavesys.com/en/products-services.html
Nemo
Цитата(joyrider @ 30.05.2011, 19:27) *
Цитата(Nemo @ 30.05.2011, 17:41) *
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
Даже в теории Fermi он не догоняет даже с 48ю ядрами,

Вот здесь вот поподробнее пожалуйста. Характеристики Fermi и MIC.

За Fermi возьмём GF580 - топовая одночиповая видеокарта Nvidia на данный момент. Топовая производительность 1581.1GFlops (FMA). [по данным википедии]. Производительность MIC легко посчитать, скажем, для 2GHz, по статье на Ананде, на которую уже ссылались. Одно ядро делает 16 SP операций за такт, умножаем на 50 ядер, на 2GHz - примерно 1600GFlops в будущем, а у NVidia столько уже сейчас.

Секундочку,
Давайте по порядку. Длина вектора MIC 512 бит, т.е. 64 байта или 16 single float. Я думаю, что векторная архитектура MIC будет уметь делать FMA, так как эту операцию хотели воткнуть даже в AVX Sandy Bridge. А вот про 2GHz я что-то не уверен. Скорее всего будет что-то типа 1.4GHz. При таких параметрах получаем 2.2GFLOPS.
К тому моменту, когда MIC выйдет на рынок я думаю NVIDIA предложит что-то похожее по производительности ну или не на много выше. Опять же Intel делает акцент не на производительность, а на удобство использования. Поэтому, железо которое будет на 5-10% медленнее чем конкуренты всё равно будет востребованным, если процесс портирования софта под него будет безболезненным.

NVidia тоже умеет делать FMA (2FMA/такт на одном SM) именно они и использовались в данной метрике как 1FLOP (не зря FMA указано в метрике для NVidia), так что всё по-честному. Про частоты ничего не знаю, так что брал с запасом. А так мои подсчёты с вашими совпадают.
Nemo
Цитата(joyrider @ 30.05.2011, 19:43) *
Цитата(Nemo @ 30.05.2011, 17:50) *
Цитата(joyrider @ 30.05.2011, 10:20) *
Цитата(Nemo @ 30.05.2011, 9:27) *
однако вопрос вовсе не в этом: из-за гораздо более простой програмной модели конкурировать он будет вовсе не с Fermi, а с обычным многопроцессорным и многоядерным железом Интел и АМД.

Это как это? MIC такая же карта как и Fermi и для того, чтобы на ней считать, нужно закачивать на нее данные и код и учитывать время закачки, которое должно быть меньше времени исполнения самой программы на карте.
Более того MIC построен на in-order архитектуре P54C, а это никогда не будет конурентом многоядерного out-of-order железа от Интел и АМД, так как изначально задачи у них разные

Да ну...
Суперкомпьютеры (а именно туда собирается MIC) уже сейчас строятся как на OOO-железе от Intel и AMD, так и на карточках NVidia. И задачи они решают совершенно одинаковые - прогноз погоды, физическое моделирование, биоинформатика и т.п. Так что конкурировать он будет именно с ними: грубо говоря, при покупке нового суперкомпьютера вопрос будет стоять ставить кучу Xeon и пускать существующий код, кучу MIC и несколько изменить код или кучу Tesla и переписать приложение под CUDA.

Давайте не будем всё сваливать в одну кучу. Есть разные задачи и они по разному выполняются на различных архитектурах. Это факт. Что-то быстрее идет на CUDA чем на Intel ® 64, а что-то и наоборот. Иначе все бы уже давно перешли на железо CUDA smile.gif Но уже сейчас не стоит вопрос о том, что ставить. Все ставят Intel или AMD, а для высокопроизводительных вычислений дополнительно ставят железо от NVIDIA, хотя бы потому, что метрика FLOPS/WATT всяко лучше у последнего. Взгляните на http://www.top500.org/. Поэтому MIC будет конкурировать именно с NVIDIA.
В данной редакции Top500 среди первых 10 систем только 3 используют Nvidia (1,3,4). Кроме того, не ясно как этот тезис согласуется с вашими же тезисами из начала этой темы о том, что NVidia не так уж быстра по сравнению с обычными процессорами.

Цитата(joyrider @ 30.05.2011, 19:43) *
Цитата(Nemo @ 30.05.2011, 9:27) *
Затраты на пересылку данных действительно существуют и там и там, но как раз они более-менее скрыты от программиста (ну точнее это не самое сложное в переписывании), сложнее изменить алгоритм, чтобы удовлетворить все требованния на CUDA Kernels, а MIC этого требовать не будет.

А вот позвольте не согласиться. Пересылка данных это удовольствие дорогое. Я вам советую почитать что такое асинхронная передача данных в документе "CUDA C Best Practices Guide", раздел "Asynchronous Transfers and Overlapping Transfers with Computation". Если в вашем алгоритме невозможна такая передача, (т.е. вы не можете отправлять последующую порцию данных в тот момент пока вычисляется предыдущая) то PCI шина для вас может стать барьером и выгоднее будет считать на CPU.
sorry за орфографические ошибки, у меня на этом компе не стоит лицензионный офис

Речь больше шла о програмной модели нежели об аспектах её поддержки в библиотеках, драйверах и т.п. В любом случае аспекты передачи данных будут в програмной модели для MIC не сложнее, чем в CUDA или OpenCL, а вот возможности кода исполняемого на карте несравнимо шире. Возможность переноса готовыхз кусков кода на карту, а не переписывание их на "шейдерном подмножестве С" делают програмную модель для MIC привлекательной.

joyrider
Цитата(Nemo @ 31.05.2011, 22:28) *
В данной редакции Top500 среди первых 10 систем только 3 используют Nvidia (1,3,4). Кроме того, не ясно как этот тезис согласуется с вашими же тезисами из начала этой темы о том, что NVidia не так уж быстра по сравнению с обычными процессорами.

Я не вижу каких либо противоречий
Nemo
Ну вот и AMD подтянулась.... Graphics Core Next (GCN) ничего не напоминает? (ответ на последней странице обзора) Дежавю не покидало меня со третьей страницы обзора и до конца.
joyrider
Цитата(Nemo @ 18.06.2011, 23:01) *
Ну вот и AMD подтянулась.... Graphics Core Next (GCN) ничего не напоминает? (ответ на последней странице обзора) Дежавю не покидало меня со третьей страницы обзора и до конца.

Anandtech изо всех сил пыталась написать статью по прочтению которой не сложилось бы впечатления что AMD готовит MIC'подобное железо. Видимо не без поддержки AMD писалась статья smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Русская версия IP.Board © 2001-2024 IPS, Inc.