OpenCL: внутренние тесты реализации в MQL5 - страница 33
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Андрей, а, скажем, Intel + Radeon - это совсем плохо?
Не плохо, просто неоправданно дороже (из за процессора). :)
ЗЫ К слову, я давний поклонник карточек от nVidia. У меня даже где то системник лежит с легендарной GeForce 3. И, если бы комп выбирался для игр, то я бы не задумываясь остался верен "зелёному" производителю графических чипов.
По серьёзному - жутко интересно какие соки ты сможешь из неё выжать. Особенно хорошо, что у тебя 2 Гига DDR5. Как выяснилось бортовая GPU-память может быть ОЧЕНЬ серьёзным ресурсом для OpenCL-вычислений.
Из набора информации что мне доступна я сделал вывод, что главным ресурсом является количество ядер GPU, при их недостатке задача разбивается на последовательные запуски ядер с новыми нитями, но на этом ресурсе трудно с экономить при покупке карточки, тк чем больше ядер тем больше цена.
Второй по важности есть скорость на которой работает память GPU (поскольку к памяти происходит довольно частое обращение). GPU задачи в большинстве своём довольно примитивные и используют 1-2-3 операции перед обращением к памяти для вывода результата. Какие либо сложные логические операции противопоказаны GPU, поэтому программерская мысль будет стремиться к их минимизации, что логично приведёт к более частому обращению к памяти. Тут есть варианты, если задача описана программистом так чтоб как можно меньше обращаться к памяти то этот ресурс не так важен.
И третьим ресурсом я бы назвал объём памяти GPU. Тк по результатам краш-тестов выяснил что не зависимо от количества одновременно существующих контекстов вся распределённая в контекстах память распределена на одном поле памяти и непересекается. Поясню примером: если вы имеете N контекстов в каждом из которых буффера распределили по 1/4 памяти девайса то таких контекстов вы можете одновременно иметь 4. Под пятый контекст, даже если вы его и создадите не будет выделена память тк она уже вся распределена предыдущими контекстами. Хотя освободив память в каком либо из предыдущих (по просту говоря удалив буффер(а)) место появится и пятый контекст отработает нормально.
Пока рано - нам нужно добиться гарантии, что 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, и на его основе защивать в байт-код оптимизацию под девайс. А то ведь мы так до ассемблера докатимся, когда придётся программисту предугадывать на какой карточке возможно будет запускаться программа и усреднять подребности проги под возможную среду использования.
Расскажи-ка, если не трудно, как прогнать тест? Где, что изменить? Копирую, выбираю, результат:
Win7 x64 билд 607
Этот пример не нужно "прогонять" в тестере. Для запуска скрипта необходимо перетащить его мышью из "Навигатора" на график. Результат отобразится в панели “Инструменты” вкладка “Эксперты”.
w7 32 разр 4GB ( 3.5GB доступно)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) против Radeon HD 5770
w7 32 разр 4GB ( 3.5GB доступно)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) против Radeon HD 5770
Круто. Ну теперь знаешь куда рыть... :)
по процессорам уже 2-3 поколения отстал
и видео 5770 - 6770 -7770
:)
Из набора информации что мне доступна я сделал вывод, что главным ресурсом является количество ядер GPU, при их недостатке задача разбивается на последовательные запуски ядер с новыми нитями, но на этом ресурсе трудно с экономить при покупке карточки, тк чем больше ядер тем больше цена.
Второй по важности есть скорость на которой работает память GPU (поскольку к памяти происходит довольно частое обращение). GPU задачи в большинстве своём довольно примитивные и используют 1-2-3 операции перед обращением к памяти для вывода результата. Какие либо сложные логические операции противопоказаны GPU, поэтому программерская мысль будет стремиться к их минимизации, что логично приведёт к более частому обращению к памяти. Тут есть варианты, если задача описана программистом так чтоб как можно меньше обращаться к памяти то этот ресурс не так важен.
И третьим ресурсом я бы назвал объём памяти GPU. Тк по результатам краш-тестов выяснил что не зависимо от количества одновременно существующих контекстов вся распределённая в контекстах память распределена на одном поле памяти и непересекается. Поясню примером: если вы имеете N контекстов в каждом из которых буффера распределили по 1/4 памяти девайса то таких контекстов вы можете одновременно иметь 4. Под пятый контекст, даже если вы его и создадите не будет выделена память тк она уже вся распределена предыдущими контекстами. Хотя освободив память в каком либо из предыдущих (по просту говоря удалив буффер(а)) место появится и пятый контекст отработает нормально.
после обновления на 607 билд у меня на ноуте внезапно заработал opencltest https://www.mql5.com/ru/code/825 , раньше не работало(недели две назад), кажется писал "OpenCL not found"
"спиной чую подвох", еще с фракталами Мандельброта не возился ))))))))))))) , но все равно приятно, что уже не новый ноут может пригодиться для полноценного тестирования МТ5