Какое будущее у GPU в вычислении?

Ваш процессор может быть четырехъядерным, но знаете ли вы, что некоторые графические карты сегодня имеют более 200 ядер? Мы уже видели, какие графические процессоры в графических картах сегодня могут делать, когда речь заходит о графике. Теперь их можно использовать и для неграфических задач, и, на мой взгляд, результаты - не что иное, как удивительные. Алгоритм, который хорошо поддается parallelism, может быть намного быстрее на GPU, чем когда-либо на CPU.

Существует несколько технологий, которые делают все возможное:

1.) CUDA от NVidia. Это, кажется, самый известный и хорошо документированный. К сожалению, он будет работать только на видеокартах NVidia. Я загрузил SDK, опробовал некоторые образцы, и там были некоторые потрясающие вещи, которые делались в CUDA. Но тот факт, что он ограничивается картами NVidia, заставляет меня сомневаться в его будущем.

2.) Stream от ATI. ATI, эквивалентный CUDA. Как и следовало ожидать, он будет работать только на картах ATI.

3.) OpenCL. Группа Khronos собрала этот стандарт, но все еще находится в зачаточном состоянии этапы. Мне нравится идея OpenCL. Надеемся, что он должен быть поддержан большинством производителей видеокарты и должен значительно упростить разработку кросс-видеокарты.

Но какие другие технологии для неграфического программирования графического процессора приходят и что наиболее перспективно? И видите ли вы, или хотели бы, чтобы эти технологии были встроены в некоторые основные разработки, такие как .NET, чтобы сделать это намного проще?

Ответ 1

Я предвижу, что эта технология станет популярной и популярной, но для этого потребуется некоторое время. Моя догадка составляет от 5 до 10 лет.

Как вы правильно отметили, одним из основных препятствий для принятия технологии является отсутствие общей библиотеки, которая работает на большинстве адаптеров - как ATI, так и nVidia. До тех пор пока это не будет разрешено в приемлемой степени, технология не войдет в основное русло и не останется в нише пользовательских приложений, работающих на определенном оборудовании.

Что касается интеграции с С# и другими управляемыми языками высокого уровня - это займет немного больше времени, но XNA уже демонстрирует, что пользовательские шейдеры и управляемая среда могут смешиваться вместе - в определенной степени. Конечно, код шейдера все еще не в С#, и есть несколько серьезных препятствий для этого.

Одной из основных причин быстрого выполнения кода GPU является то, что он имеет серьезные ограничения на то, что код может и не может сделать, и использует VRAM вместо обычной RAM. Это затрудняет объединение кода процессора и кода графического процессора. В то время как обходные пути возможны, они практически отрицают прирост производительности.

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Просто потому, что он называется "смущающий" параллель, не означает, что это не очень важное поле.

Я работал в нескольких финансовых домах, и мы видим, что мы можем выбросить фермы из 1000 двигателей montecarlo (много стеков лопаток, выстроенных вместе) для нескольких крупных установок NVidia CUDA - массовое снижение затрат на электроэнергию и тепло в центр обработки данных.

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

В принципе, однако, такие технологии находятся на уровне абстракции ниже, чем управляемый язык выполнения, такой как С#, мы говорим об аппаратных устройствах, которые запускают свой собственный код на своих собственных процессорах.

Интеграция сначала должна быть выполнена с Matlab, Mathematica, которую я ожидаю, вместе с API C, конечно...

Ответ 4

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

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

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

На практике в наши дни уже довольно много высокопроизводительных числовых программ не выполняют свое собственное низкоуровневое программирование, но полагаются на библиотеки. На аппаратном обеспечении Intel, если вы делаете число-хруст, обычно трудно обыграть математические библиотеки Intel (MKL) для большинства вещей, которые он реализует, - и использование их означает, что вы можете получить преимущества всех векторных инструкций и умные трюки в новых процессорах x86, без необходимости специализироваться на вашем коде для них. С такими вещами, как GPU, я подозреваю, что это станет еще более распространенным.

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Таким образом, графический процессор может быть невероятно быстрым для проблем, когда вы можете разделить данные правильно и самостоятельно обрабатывать разделы. Это не так сильно на Задача (поток) Уровень Parallelism.

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

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

Еще одна серьезная проблема с графическим процессором заключается в том, что, если вы НЕ ОСТОРОЖНЫ думать о том, как организованы ваши данные, вы пострадали от внутренней производительности (в графическом процессоре). Это часто включает в себя переписывание очень простого кода в извилистую кучу мусора.

Ответ 12

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

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

Ответ 13

Справедливо, что графические процессоры могут достигать очень высоких показателей производительности в ситуациях уровня данных parallelism, как много здесь упоминалось. Но, как я вижу, в пользовательском пространстве сейчас мало пользы. Я не могу понять, что вся эта пропаганда GPGPU поступает от производителей графических процессоров, которые просто хотят найти новые рынки и использовать их продукты. И это абсолютно нормально. Вы когда-нибудь задумывались над тем, почему Intel/amd не включили некоторые мини-x86 ядра в дополнение к стандартным (скажем, модель с четырьмя ядрами x86 и 64 мини-x86-ядрами), просто чтобы повысить уровень паралелизма данных на уровне данных? Они определенно могли это сделать, если захотят. Я предполагаю, что индустрия просто не нуждается в такой мощности обработки на обычных настольных/серверных машинах.

Ответ 14

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

Intel выпускает новый ускоритель, называемый Xeon Phi, который, как они надеются, может оспорить GPU как ускоритель HPC. Cell-процессор применял аналогичный подход, имея один основной процессор для выполнения общих задач и выгружая вычислительные интенсивные задачи для некоторых других элементов обработки, добиваясь впечатляющих скорости.

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

Ответ 15

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

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

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

Ответ 16

Я ожидаю те же самые вещи, что и процессоры?

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