Какое будущее GPU имеет в вычислениях? [закрытый]

Я ожидаю того же, для чего используются процессоры?

Я просто хочу сказать, что это кажется мне уловкой. Я не решаюсь сказать «это никуда не денется», когда речь заходит о технологиях, но основная функция графических процессоров - это рендеринг графики, а основная функция процессора - вся остальная обработка. Когда графический процессор делает что-то еще, кажется странным.

Ваше мнение о том, что графические процессоры быстрее, чем процессоры, основано на заблуждении, созданном несколькими ужасно параллельными приложениями, применяемыми к подобным устройствам PS3, NVIDIA и ATI.

http: // en.wikipedia.org/wiki/Embarrassingly_parallel

Большинство реальных задач нелегко разложить на эти типы задач. ЦП для настольных ПК лучше подходит для этого типа задач как с точки зрения набора функций, так и с точки зрения производительности.

Графические процессоры хорошо работают в задачах с высоким уровнем параллелизма уровня данных , что по сути означает, что есть способ разбить данные для обработки. так что все они могут быть обработаны.

По своей природе графические процессоры не так быстры на уровне тактовой частоты. На самом деле я почти уверен, что тактовая частота шейдеров (или, может быть, в наши дни для них используется термин GPGPU?) Довольно медленная по сравнению с ALU на современных процессорах для настольных ПК. Дело в том, что GPU имеет огромное количество этих шейдеров, превращая GPU в очень большой SIMD процессор. Например, при большом количестве шейдеров на современном Geforce графический процессор может работать с несколькими сотнями (тысячами?) Чисел с плавающей запятой одновременно.

Итак, короче, графический процессор может быть удивительно быстрым для проблем, когда вы можете правильно разделить данные и обработать разделы независимо. Это не так эффективно на Параллелизме на уровне задач (потоков) .

Я слышал много разговоров о том, что сегодня графические процессоры превращаются в более универсальные «процессоры массива», предназначенные для использования с любой математической задачей , а не только для обработки графики. Однако я еще не видел, чтобы из этого получилось много.

Теория заключалась в том, что процессоры массивов могли следовать примерно по той же траектории, по которой процессоры с плавающей запятой следовали пару десятилетий назад. Первоначально процессоры с плавающей запятой были дорогими дополнениями к ПК, которые не многие люди удосужились купить. В конце концов они стали настолько жизненно важными, что были помещены в сам процессор.

Важно помнить, что даже задачи, которые изначально являются последовательными, могут выиграть от распараллеливания, если они должны выполняться много раз независимо.

Также помните, что всякий раз, когда кто-либо сообщает об ускорении реализации GPU с реализацией CPU, это почти никогда не бывает справедливым сравнением. Чтобы быть по-настоящему справедливым, разработчики должны сначала потратить время на создание действительно оптимизированной параллельной реализации ЦП. Один процессор Intel Core i7 965 XE сегодня может достигать около 70 гигафлопс с двойной точностью. Современные высокопроизводительные графические процессоры могут выполнять 70-80 гигафлопс с двойной точностью и около 1000 с одинарной точностью. Таким образом, ускорение более 15 может означать неэффективную реализацию ЦП.

Одно важное предостережение относительно вычислений на ГП состоит в том, что они в настоящее время являются «маломасштабными». Благодаря суперкомпьютерам, вы можете запустить распараллеленный алгоритм на сотнях или даже тысячах ядер ЦП. Напротив, «кластеры» графических процессоров в настоящее время ограничены примерно 8 графическими процессорами, подключенными к одной машине. Конечно, несколько из этих машин могут быть объединены вместе, но это добавляет дополнительную сложность, поскольку данные должны передаваться не только между компьютерами, но и между графическими процессорами. Кроме того, еще не существует эквивалента MPI, который позволяет прозрачно масштабировать процессы для нескольких графических процессоров на нескольких машинах; он должен быть реализован вручную (возможно, в сочетании с MPI).

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

Возможно, самым многообещающим претендентом на будущее является Larrabee от Intel. У него значительно лучший доступ к процессору, системной памяти и, что, возможно, наиболее важно, к кэшированию. Это должно дать ему значительные преимущества для многих алгоритмов. Однако, если он не может соответствовать огромной пропускной способности памяти на текущих графических процессорах, он может отстать от конкурентов в отношении алгоритмов, которые оптимально используют эту пропускную способность.

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

Отметим также, что усилия, необходимые для достижения оптимальной производительности, необходимы для оправдания использования оборудования GPU. Разница между наивной реализацией и оптимизированной реализацией может быть на порядок или больше. Это означает, что оптимизированная реализация ЦП, вероятно, будет столь же хороша или даже лучше, чем наивная реализация GPU.

Люди уже работают над привязками .NET для CUDA. См. здесь . Однако, учитывая необходимость работы на низком уровне, я не думаю, что вычисления на GPU уже готовы для массового использования.

Практически все, что можно сопоставить, может быть польза. Более конкретные примеры: SETI @ home , fold @ home., и другие распределенные проекты, а также научные вычисления.

Особенно вещи, которые сильно зависят от арифметики с плавающей запятой. Это потому, что графические процессоры имеют специализированную схему, которая ОЧЕНЬ быстро выполняет операции с плавающей запятой. Это означает, что он не такой универсальный, но он ОЧЕНЬ хорош в том, что делает.

Если вы хотите взглянуть на более специализированную обработку GPU, посмотрите GPU Tesla от Nvidia . Это графический процессор, но на самом деле у него нет вывода на монитор!

Я сомневаюсь, что мы увидим слишком много обработки графическим процессором на обычном рабочем столе или, по крайней мере, на какое-то время, потому что не у всех есть видеокарта с поддержкой CUDA или аналогичной. , если у них вообще есть видеокарта. Также очень сложно сделать программы более параллельными. Игры могли бы использовать эту дополнительную силу, но это будет очень сложно и, вероятно, выиграет »

Монте-Карло до неприличия параллельна, но это основной метод финансовых и научных вычислений.

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

Многие поддающиеся отслеживанию научные исследования проводятся с использованием того, что может быть выражено досадно параллельным образом.

Просто потому, что это названо "

Я думаю, вы можете считать следующий DirectX другим способом

По моему опыту, графические процессоры чрезвычайно быстры для алгоритмов, которые легко распараллелить. Недавно я оптимизировал специальный алгоритм изменения размера изображения в CUDA, чтобы он был более чем в 100 раз быстрее на графическом процессоре (даже не на высокопроизводительном), чем четырехъядерный процессор Intel. Проблема заключалась в передаче данных на графический процессор, а затем в загрузке результата обратно в основную память, причем оба направления ограничивались скоростью memcpy () на этой машине, которая составляла менее 2 ГБ / с. В результате алгоритм оказался ненамного быстрее, чем версия CPU ...

Так что это действительно зависит от обстоятельств. Если у вас есть научное приложение, в котором вы можете хранить большую часть данных на графическом процессоре, а все алгоритмы сопоставляются с реализацией графического процессора, тогда все в порядке. В противном случае я бы подождал, пока не появится более быстрый канал между CPU и GPU, или давайте посмотрим, что у ATI есть в рукавах с комбинированным чипом ...

О том, какую технологию использовать: я думаю, когда вы начнете работать на CUDA, дополнительный шаг для переноса его на OpenCL (или другой язык) не такой уж и большой. Вы проделали всю тяжелую работу, распараллеливая свои алгоритмы, а остальное - просто другой «вкус»

О том, какую технологию использовать: я думаю, что после того, как вы запустите свой материал на CUDA, дополнительный шаг по переносу его на OpenCL (или другой язык) не будет такой большой. Вы проделали всю тяжелую работу, распараллеливая свои алгоритмы, а остальное - просто другой «вкус»

О том, какую технологию использовать: я думаю, что после того, как вы запустите свой материал на CUDA, дополнительный шаг по переносу его на OpenCL (или другой язык) не будет такой большой. Вы проделали всю тяжелую работу, распараллеливая свои алгоритмы, а остальное - просто другой «вкус»

Исследователи GHC (Haskell) (работающие в Microsoft Research) добавляют поддержку параллелизма вложенных данных непосредственно в язык программирования общего назначения. Идея состоит в том, чтобы использовать несколько ядер и / или графических процессоров на задней панели, но при этом предоставлять параллельные массивы данных как собственный тип языка, независимо от среды выполнения, выполняющей код параллельно (или последовательно для резервной конфигурации с одним процессором).

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

В зависимости от успеха этого в следующие несколько лет, я ожидал бы, что другие языки (особенно C #) подхватят эту идею, что могло бы донести такие возможности до более широкой аудитории. Возможно, к тому времени проблемы с пропускной способностью CPU-GPU и драйверами будут решены.

Большая проблема с технологией GPU состоит в том, что, хотя у вас есть много вычислительных возможностей, , получение данных (и выход из него) ужасно (с точки зрения производительности). И внимательно следите за любыми сравнительными тестами ... они часто сравнивают gcc (с минимальной оптимизацией, без векторизации) на однопроцессорной системе с графическим процессором.

Еще одна большая проблема с графическим процессором заключается в том, что если вы не будете ВНИМАТЕЛЬНО думать о как организованы ваши данные, вы испытаете реальный удар по производительности внутри (в GPU). Это часто связано с переписыванием очень простого кода в запутанную кучу мусора.

Мне очень нравится эта технология. Однако я думаю, что это только усугубит реальную проблему больших параллельных задач, связанную с пропускной способностью. Добавление большего количества ядер только усилит конкуренцию за память. OpenCL и другие библиотеки абстракции GPGPU не предлагают никаких инструментов для улучшения этого.

Любая высокопроизводительная вычислительная аппаратная платформа обычно разрабатывается с учетом проблемы пропускной способности, тщательно спланированной с учетом аппаратного обеспечения, балансировки пропускной способности, задержки, кэширования и стоимости. Пока стандартное оборудование, ЦП и ГП, спроектировано изолированно друг от друга, с оптимизированной пропускной способностью только для их локальной памяти, будет очень трудно улучшить это для алгоритмов, которые в этом нуждаются.

Я повторю ответ, который я дал здесь.

В долгосрочной перспективе я думаю, что GPU перестанет существовать, поскольку процессоры общего назначения будут развиваться, чтобы взять на себя эти функции. Intel Larrabee - это первый шаг. История показала, что делать ставки против x86 - плохая идея.

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

Например, AMD Stream 2.0 SDK включает версию их библиотеки BLAS (линейной алгебры) с некоторыми вычислениями, реализованными на GPU. . API точно такой же, как и их версия библиотеки только для ЦП, которую они поставляли годами; все, что нужно, - это повторно связать приложение, оно использует графический процессор и работает быстрее.

Точно так же Дэн Кэмпбелл из GTRI работал над реализацией CUDA стандарта VSIPL для обработки сигналов. (В частности, вид обработки сигналов и изображений, распространены в радиолокационных системах и связанных с ними вещах, таких как медицинская визуализация.) Опять же, это стандартный интерфейс, и приложения, написанные для реализации VSIPL на других процессорах, можно просто перекомпилировать с этим и использовать возможности графического процессора, где это необходимо. На практике в наши дни уже довольно много высокопроизводительных числовых программ не выполняют свое собственное низкоуровневое программирование, а полагаются на библиотеки. На оборудовании Intel, если вы занимаетесь вычислением чисел, обычно трудно превзойти математические библиотеки Intel (MKL) для большинства реализуемых им вещей - и их использование означает, что вы можете получить преимущества всех векторных инструкций и хитрые приемы в новых процессорах x86, без необходимости специализировать свой код для них. Я подозреваю, что с такими вещами, как графические процессоры, это станет еще более распространенным.

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

(Отказ от предвзятости: моя компания также работает над портом CUDA для нашей библиотеки VSIPL ++, поэтому я склонен думать, что это хорошая идея!)

Кроме того, в совершенно другом направлении вы можете проверить некоторые вещи, которые делает RapidMind. Их платформа изначально предназначалась для многоядерных систем типа ЦП, но они проделали большую работу по распространению ее и на вычисления на GPU.

(отказ от предвзятости: моя компания также работает над портом CUDA для наша библиотека VSIPL ++, так что я склонен думать, что это хорошая идея!)

Кроме того, в совершенно другом направлении вы можете проверить некоторые вещи, которые делает RapidMind. Их платформа изначально предназначалась для многоядерных систем типа ЦП, но они проделали большую работу по распространению ее и на вычисления на GPU.

(отказ от предвзятости: моя компания также работает над портом CUDA для наша библиотека VSIPL ++, так что я склонен думать, что это хорошая идея!)

Кроме того, в совершенно другом направлении вы можете проверить некоторые вещи, которые делает RapidMind. Их платформа изначально предназначалась для многоядерных систем типа ЦП, но они проделали большую работу по распространению ее и на вычисления на GPU.

Кроме того, в совершенно другом направлении вы можете проверить некоторые вещи что делает RapidMind. Их платформа изначально предназначалась для многоядерных систем типа ЦП, но они проделали большую работу по распространению ее и на вычисления на GPU.

Кроме того, в совершенно другом направлении вы можете проверить некоторые вещи что делает RapidMind. Их платформа изначально предназначалась для многоядерных систем типа ЦП, но они проделали большую работу по распространению ее и на вычисления на GPU.