Какое будущее у графических процессоров в вычислениях?[закрыто]

https://stackoverflow.com/questions/1126989

13-09-2019
|

Вопрос

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

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

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

2.) Транслировать от АТИ.ATI эквивалент CUDA.Как и следовало ожидать, он будет работать только с картами ATI.

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

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

Решение

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

Тот факт, что она названа «смущающе» параллельной, не означает, что она не является чрезвычайно важной областью.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow