OpenCL: внутренние тесты реализации в MQL5 - страница 33

 
Mathemat:

Андрей, а, скажем, Intel + Radeon - это совсем плохо?

Не плохо, просто неоправданно дороже (из за процессора). :)

ЗЫ К слову, я давний поклонник карточек от nVidia. У меня даже где то системник лежит с легендарной GeForce 3. И, если бы комп выбирался для игр, то я бы не задумываясь остался верен "зелёному" производителю графических чипов.

 
Лови пост в личку тут. Не хочется выносить его сюда.
 
MetaDriver:
По серьёзному - жутко интересно какие соки ты сможешь из неё выжать.  Особенно хорошо, что у тебя 2 Гига DDR5.  Как выяснилось бортовая GPU-память может быть ОЧЕНЬ серьёзным ресурсом для OpenCL-вычислений.

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

Второй по важности есть скорость на которой работает память GPU (поскольку к памяти происходит довольно частое обращение). GPU задачи в большинстве своём довольно примитивные и используют 1-2-3 операции перед обращением к памяти для вывода результата. Какие либо сложные логические операции противопоказаны GPU, поэтому программерская мысль будет стремиться к их минимизации, что логично приведёт к более частому обращению к памяти. Тут есть варианты, если задача описана программистом так чтоб как можно меньше обращаться к памяти то этот ресурс не так важен.

И третьим ресурсом я бы назвал объём памяти GPU. Тк по результатам краш-тестов выяснил что не зависимо от количества одновременно существующих контекстов вся распределённая в контекстах память распределена на одном поле памяти и непересекается. Поясню примером: если вы имеете N контекстов в каждом из которых буффера распределили по 1/4 памяти девайса то таких контекстов вы можете одновременно иметь 4. Под пятый контекст, даже если вы его и создадите не будет выделена память тк она уже вся распределена предыдущими контекстами. Хотя освободив память в каком либо из предыдущих (по просту говоря удалив буффер(а)) место появится и пятый контекст отработает нормально.

Renat:

Пока рано - нам нужно добиться гарантии, что OpenCL программы не повесят всю сеть из-за глюков GPU и самих OpenCL программ.

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

Задача распределённой сети параллельных вычислений. Само название может поставить неподготовленного читателя в тупик. Если с организацией распределённой сети на многоядерных машинах вы имели проблемы то теперь их будет в квадрате. Все ядра можно было считать отдельными юнитами сети, поскольку они выполняют раздельные задачи. Но раньше скорость их исполнения различалась максимум в 2-3 раза (для чего вы ввели ограничения на медленные ядра), количество памяти в большинстве не играло роли тк массивы имеют по 10^7 элементов максимум (для современных машин это копейки).

Но вот с GPU задача кардинально меняется. Во первых всего лишь ~12 массивов double длинны 10^7 это уже 1Гб, для многих карточек это предел. А в CPU расчётах запросто встречаются задачи и с большим количеством буфферов (хотя конечно на GPU программист может прописать использовать память хоста, но это решение сродни использования виртуальной оперативы, короче бэд).

Во вторых разница в скоростях выполнения линейно зависима от количества ядер в GPU. И различия меду карточками в 10-1000 раз.

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

Хотя задача немного упрощается благодаря унификации применённой самим временем. Карточка с 12-ю ядрами наверняка имеет 256 Мб, с 96-ю 512 Мб. В среднем производители не допускают больших перекосов (в отличии от CPU где пользователь сам может на старый камушек воткнуть оперативы по самые небалуй, или наоборот на новом камне оперативы минимум поставить, чисто для экономии при покупке).

Хотя на мой взгляд, более правильный подход будет в создании дебагера под OpenCL, и на его основе защивать в байт-код оптимизацию под девайс. А то ведь мы так до ассемблера докатимся, когда придётся программисту предугадывать на какой карточке возможно будет запускаться программа и усреднять подребности проги под возможную среду использования.

 
MetaDriver:

Расскажи-ка, если не трудно, как прогнать тест? Где, что изменить? Копирую, выбираю, результат: 

 

Win7 x64   билд 607

 
WChas:

Этот пример не нужно "прогонять" в тестере. Для запуска скрипта необходимо перетащить его мышью из "Навигатора" на график. Результат отобразится в панели Инструменты вкладка Эксперты.

 

w7  32 разр  4GB   ( 3.5GB доступно)  

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) против   Radeon HD 5770

 

 
Snaf:

w7  32 разр  4GB   ( 3.5GB доступно)  

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) против   Radeon HD 5770

Круто.  Ну теперь знаешь куда рыть... :)
 
MetaDriver:
Круто.  Ну теперь знаешь куда рыть... :)

по процессорам уже 2-3 поколения отстал

и видео  5770 - 6770 -7770 

:) 

 
Urain:

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

Второй по важности есть скорость на которой работает память GPU (поскольку к памяти происходит довольно частое обращение). GPU задачи в большинстве своём довольно примитивные и используют 1-2-3 операции перед обращением к памяти для вывода результата. Какие либо сложные логические операции противопоказаны GPU, поэтому программерская мысль будет стремиться к их минимизации, что логично приведёт к более частому обращению к памяти. Тут есть варианты, если задача описана программистом так чтоб как можно меньше обращаться к памяти то этот ресурс не так важен.

И третьим ресурсом я бы назвал объём памяти GPU. Тк по результатам краш-тестов выяснил что не зависимо от количества одновременно существующих контекстов вся распределённая в контекстах память распределена на одном поле памяти и непересекается. Поясню примером: если вы имеете N контекстов в каждом из которых буффера распределили по 1/4 памяти девайса то таких контекстов вы можете одновременно иметь 4. Под пятый контекст, даже если вы его и создадите не будет выделена память тк она уже вся распределена предыдущими контекстами. Хотя освободив память в каком либо из предыдущих (по просту говоря удалив буффер(а)) место появится и пятый контекст отработает нормально.

Николай, я с тобой согласен по поводу индивидуальной иерархии ценностей.  А вот касаемо облака.. проблемы упрутся именно в память.  Если первых двух ресурсов на облачной машине недостаточено, программа клиента будет просто тормозить. Сильно/слабо тормозить - вопрос десятый.  Ну отрегулируют ей статус ипсё.  А вот при недостатке GPU-памяти она может просто упасть. Т.е. если драйвер отказывает в распределении буфера - это полбеды. Беда если памяти в принципе хватает, но не остаётся для остальных GPU-контекстов (включая системные). Тогда драйвер просто рвётся (как показала практика). Возможно это просто недоработка в дровах, но пока она есть, лучше OpenCL-ные программы в облако не пущать. Удалённым агентам можно, а в облако не стоит.
 

после обновления на 607 билд у меня на ноуте внезапно заработал opencltest https://www.mql5.com/ru/code/825 , раньше не работало(недели две назад), кажется писал "OpenCL not found"

"спиной чую подвох", еще с фракталами Мандельброта не возился ))))))))))))) , но все равно приятно, что уже не новый ноут может пригодиться для полноценного тестирования МТ5

OpenCL Test
OpenCL Test
  • голосов: 10
  • 2012.02.07
  • MetaQuotes Software
  • www.mql5.com
Небольшой рабочий пример расчета фрактала Мандельброта в OpenCL, который кардинально ускоряет расчеты по сравнению с софтверной реализацией примерно в 100 раз.