OpenCL: внутренние тесты реализации в MQL5 - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если правильно понял, то 1 GPU - это один очень мощный агент? Можно в таком случае процессорные агенты отключить (из-за их малой скорости по отношению к видео)? И повторюсь: можно два ATI без кроссфайра?
AMD крайне не рекомендует использовать Crossfire для OpenCL - так как при кросфайре фактически два GPU, но драйвер САМ делит между ними ОДНО графическое задание. Напротив, для OpenCL 1.1 нет пока способа драйверу видеокарты самому делить одно OpenCL задание между двумя GPU (смотреть выше).
То же самое для nvidia SLI.
Как скажется включение OpenCL на стоимость расчетов в облаке?
Стоимость агента с GPU будет выше стоимости агента без GPU, т.к. расчетное время первого агента будет значительно короче?
С учетом того, что только одному агенту на локальной машине будет даваться GPU, получается, что стоимость разных агентов на одной и той же локальной машине будет разной (и заранее вычисленной)?
Как скажется включение OpenCL на стоимость расчетов в облаке?
Стоимость агента с GPU будет выше стоимости агента без GPU, т.к. расчетное время первого агента будет значительно короче?
С учетом того, что только одному агенту на локальной машине будет даваться GPU, получается, что стоимость разных агентов на одной и той же локальной машине будет разной (и заранее вычисленной)?
По умолчанию терминал/агент на старте сам выбирает наиболее мощное GPU устройство по набору его возможностей. Пока мысли выбирать устройства из MQL5 нет - это лишь усложнит код и приведет к дополнительным ошибкам.
Вместо этого есть более красивая идея в виде автоматического распределения каждого физического GPU на отдельных агентов, что позволит их использовать в полную силу.
Допустим, есть EX5 (с использованием OpenCL), который на агентах с GPU оптимизируется в 20 раз быстрее, чем без GPU.
Запускаем оптимизацию на облаке. Очевидно, что выгоднее (с точки зрения затраченного времени) всего запускать оптимизацию в первую очередь на тех агентах, где есть физический GPU. Отдавая им основную часть вариантов перебора. Это эквивалентно тому, что их PR выше в 20 раз. НО, их PR без использования GPU такой же. Т.е. необходим ввод расчета нового PR - PR_gpu.
" При выполнении задачи работа, выполненная агентом тестирования, учитывается как произведение его PR на потраченное время Time. "
Из этой формулы следует, что если PR_gpu не будет, то стоимость всей оптимизации на облаке с GPU будет дешевле, чем без.
К сожалению, ввод альтернативного расчета PR - одиночный тестовый проход оптимизируемого EX5-файла содержит в себе огромное количество подводных камней, из-за которых невозможно его универсальное использование.
Из этой формулы следует, что если PR_gpu не будет, то стоимость всей оптимизации на облаке с GPU будет дешевле, чем без.
К сожалению, ввод альтернативного расчета PR - одиночный тестовый проход оптимизируемого EX5-файла содержит в себе огромное количество подводных камней, из-за которых невозможно его универсальное использование.
не вдаваясь в детали, которых я не знаю, если не будет пересмотрен фактический PR , то и смысла сдавать в облако с GPU нет
ещё, если вводите новое понятие , а вы это любите) ,например Стоимость агента то лучше сразу давать определение а то надо догадываться , что речь идет о стороне пользователя в данном случае
В настоящий момент PR = Const Koef / время, затраченное на выполнение эталонной задачи.
Стоимость оптимизации равно количеству эталонных задач, которые можно было бы посчитать за время, что длилась оптимизация. Т.е. стоимость расчетов не зависит от того, как облако распределяет задачи между агентами. Но от правильного распределения зависит итоговая длительность оптимизации, что является важнейшим показателем.
Понятно, что облако распределяет задачи между агентами пропорционально заранее вычисленному PR, чтобы уменьшить расчетное время (но не уменьшить стоимость - CONST).
Задачи с OpenCL конечно же будут в первую очередь отдаваться агентам с подходящим GPU.
стоимость расчетов не зависит от того, как облако распределяет задачи между агентами.
К сожалению, ввод альтернативного расчета PR - одиночный тестовый проход оптимизируемого EX5-файла содержит в себе огромное количество подводных камней, из-за которых невозможно его универсальное использование.
Поскольку стоимость для проводящего оптимизацию всегда постоянна, а вот ее длительность сильно зависит от адекватного (для данной задачи) вычисления PR, возможно, стоит ввести на совесть оптимизирующего ввод к код своего EX5 PR_calculate. Где оптимизирующий, исходя из особенностей его алгоритма, будет сам задавать вычисление распределительного PR, наиболее подходящего для его задачи.
Например, если задача чисто вычислительная - то акцент в PR_calculate сделан будет на математику.
Если задача ворочает огромные массивы данных - на скорость работы с памятью.
Если GPU используется чуть-чуть - отобразить это в своем PR_calculate.
Если же GPU используется всюду в EX5 - написать соответствующий PR_calculate (с соответствующим использованием GPU).
При такой схеме сдающие мощности в облако точно ничего не теряют, а использующие мощности облако получают возможность существенно ускорить свои расчеты.
Если же PR_calculate не задан, то используется уже принятая универсальная эталонная задача.
P.S. PR_calculate используется только для распределения задач в облаке. Для вычисления стоимости все также остается прежний PR.
P.P.S. Есть, конечно, и подводные камни - необходимо PR_calculate предварительно запустить на всех свободных агентах. PR_calculate может быть написан с ошибкой - зациклен. Поэтому за время вычисления PR_calculate тоже взымать деньгу по классической PR-схеме. И т.д.
Поскольку стоимость для проводящего оптимизацию всегда постоянна, а вот ее длительность сильно зависит от адекватного (для данной задачи) вычисления PR, возможно, стоит ввести на совесть оптимизирующего ввод к код своего EX5 PR_calculate. Где оптимизирующий, исходя из особенностей его алгоритма, будет сам задавать вычисление распределительного PR, наиболее подходящего для его задачи.