Comments 20
Если кратко, то пока только в тех случаях, где есть compute-bound или bandwidth-bound задачи. Т.е. много вычислений на каждое число, так как доступно до 2.2 TFLOP/s для одинарной точности; или же последовательный доступ к памяти — т.к. 8 контроллеров памяти с прифетчингом справятся с этой задачей лучше (реальные 160 GB/s), чем CPU (~60GB/s). Проблемы возникают, если есть случайный доступ к данным. Тут пиши — «пропало!». Прифетчинг становится бесполезным и наблюдается резкое падение пропускной способности. Такая же картина будет на GPGPU, если у вас есть опыт программирования для этих архитектур.
Можно ещё добавить, что пока Xeon Phi имеют только in-order ядра, т.е. параллелизм на уровне инструкций, как при out-of-order buffers — отсутствует. Это поменяется со следующим поколением Xeon Phi — Knights Landing.
Ну и пока мы ограничены шириной PCIe шины, которая для 2ого поколения устройств (PCIe v2 with 16 lanes) может пропускать до 7 GB/s (реальных я видел только 6.5 GB/s). Т.е. из простого расчёта можно прикинуть, что нужно минимум где-то 1200 FLOPs на каждый double, что бы оправдать перегон этих данных по шине. Опять таки это поменяется со следующим поколением, т.к. Интел решил выпустить Knights Landing как CPU чип, т.е. все куча ядер будут сидеть прям на материнской плате с доступом к сотням гигабайт памяти.
Как-то так… Я об этом буду подробно в курсе говорить.
Можно ещё добавить, что пока Xeon Phi имеют только in-order ядра, т.е. параллелизм на уровне инструкций, как при out-of-order buffers — отсутствует. Это поменяется со следующим поколением Xeon Phi — Knights Landing.
Ну и пока мы ограничены шириной PCIe шины, которая для 2ого поколения устройств (PCIe v2 with 16 lanes) может пропускать до 7 GB/s (реальных я видел только 6.5 GB/s). Т.е. из простого расчёта можно прикинуть, что нужно минимум где-то 1200 FLOPs на каждый double, что бы оправдать перегон этих данных по шине. Опять таки это поменяется со следующим поколением, т.к. Интел решил выпустить Knights Landing как CPU чип, т.е. все куча ядер будут сидеть прям на материнской плате с доступом к сотням гигабайт памяти.
Как-то так… Я об этом буду подробно в курсе говорить.
А я вот, что нашёл www.nvidia.com/object/justthefacts.html может конечно и ангажировано но всё же…
Копропроцессоры, ок.
А если по сути вопроса, пожалуйста?
Спасибо за поправку. Учту при дальнейших переводах. Хотя себя будет сложно переучить, т.к. в ангийской транскрипции это слово читается именно как «ко-», а не «со-». Это как в названии штата «Техас» отродясь не было буквы «х» (американцы произносят его как «Тексыс»), но в русском произношении — появилась, думаю из-за схожего написания ;)
Вся суть видео могла быть передана 4 сниппетами кода и 4 графиками, соответственно. С парой абзацев про объяснения.
Собственно, я сомневаюсь, что вы расскажете что-то большее, чем есть в книге «C++ Concurrency in Action: Practical Multithreading» by Anthony Williams. А прочитать её за две недельки можно, читается гораздо легче, чем просмотр данного видео :)
Собственно, я сомневаюсь, что вы расскажете что-то большее, чем есть в книге «C++ Concurrency in Action: Practical Multithreading» by Anthony Williams. А прочитать её за две недельки можно, читается гораздо легче, чем просмотр данного видео :)
Вы правы. Данный пример очень прост. Хуже дела, например, обстоят с кодом для оптимизации использования кеша. там снипет кода может не помочь, и проще будет выслушать чьё-то объяснение. В нашей книге (xeonphi.com/book) есть и такие примеры. А в целом, видео лекции создаются с двойной целью: 1) некоторые ученики предпочитают видео материал, чем чтение книг. 2) дальнейшее распространение учебного материала в странах не говорящих по-английски можно сделать просто переведя субтитры на нужный язык.
Упомянутая книга рассматривает особенности реализации параллельного доступа к С++11 структурам данных. При этом векторизация, распределённые вычисления в кластерах, оптимизация траффика, оптимизация доступа к памяти, и остальные 90% материала нашего учебного курса она не рассматривает. Так что можете, конечно, сомневаться, но я расскажу намного больше, чем покрыто в упомянутой книге.
Блин, я упоролся совсем. Конечно это не эта книга, хотел написать про www.akkadia.org/drepper/cpumemory.pdf «What every programmer should know about memory».
Да, это хорошая статья. Я её всем рекомендую, тем более, что с Уричем Дреппером я лично знаком, с тех пор когда он ещё работал в Red Hat, и приезжал к нам на кампус в North Carolina State University, где главный офис «красных шапочек» и находился. Но опять, это только работа памяти. А где векторизация, где неоднородные распределённые вычисления, я спрашиваю?..
Программа курса в целом интересна, однако предложенный видеоролик удручает. Зачем-то на протяжении 12 минут два раза объясняется тривиальная «оптимизация». Для того, видимо, чтобы в конце показать высокие синие столбики. Продемонстрировали бы их сразу на 7 минуте и дело с концом, все равно об их получении в ролике нет ни слова. Можно, правда, заметить, что использовались Cilk и OpenMP. В общем, лучше уж совсем без видео, нежели с таким.
Учтём.
Я согласен, сейчас это странно выглядит. Связано это с тем, что в начале были сняты два отдельных видео ролика: теоретическая часть отдельно от практической. Они были просто склеены вместе, когда я занялся русской озвучкой.
В дальнейшем, я думаю, стоит объединять их в месте. Т.е. при показе слайда с теоретическим объяснением можно сбоку ещё показывать изменение исходного кода программы.
В любом случае, спасибо за комментарий.
Я согласен, сейчас это странно выглядит. Связано это с тем, что в начале были сняты два отдельных видео ролика: теоретическая часть отдельно от практической. Они были просто склеены вместе, когда я занялся русской озвучкой.
В дальнейшем, я думаю, стоит объединять их в месте. Т.е. при показе слайда с теоретическим объяснением можно сбоку ещё показывать изменение исходного кода программы.
В любом случае, спасибо за комментарий.
Sign up to leave a comment.
Пилотный выпуск видео курса «Параллельное Программирование и Оптимизация для Intel Xeon Phi копроцессоров»