Возможности облачных математических расчетов.
P.P.S. Хотелось бы, чтобы облако было универсальным вычислительным ресурсом.
Есть статическая передача на агентов файлов, ее функции будут расширены динамическими запросами. Будут добавлены методы возврата результатов назад в виде файлов и массивов данных.
Также будет включена родная поддежка OpenCL без необходимости подключать DLL.
Уже реализован адаптивный механизм контроля ресурсов процессора, памяти и диска, что позволяет не передавать на слабых агентов объемные задачи.
Мат. задачи идут с файлами исходных данных. В данный момент каждый проход на агенте начинается с того, что эти данные считываются из файлов. Хотя, конечно, достаточно было бы их считать один раз.
Какие есть соображения по нивелированию подобных повторных считываний одного и того же?
Возможно, имеет смысл файлы исходных данных помещать сразу в память, чтобы пусть и были повторные считывания, но не тормозились дисковой системой каждый раз.
Самый эффективный метод для математических задач - это внутреннее/собственное пакетирование. Особенно при работе с вычитываемыми массивами данных.
То есть, не запускать 100 000 000 проходов в лоб, а сделать пакетную отработку в 100 000 проходов по 100 внутренних задач внутри.
Со своей стороны мы сами пакетируем задачи, выдавая их пачками каждому агенту. Этот механизм позволяет снижать системный оверхен на скорострельных задачах (<100 ms исполнения).
Оптимальное внутренне пакетирование подбирается индивидуально в экпериментальном порядке для разных математических задач?
Или же есть какие-то общие принципы-критерии (например, количество свободных агентов), по которым можно приблизиться к наиболее оптимальному пакетированию?
Собственное пакетирование - это внутренний оптимизатор. Каков мехнизм передачи результатов внутренней оптимизации на внешнюю? Чтобы при своем пакетировании иметь такой же результат в итоге, как если бы внутреннего пакетирования не было бы.
Оптимальное внутренне пакетирование подбирается индивидуально в экпериментальном порядке для разных математических задач?
Или же есть какие-то общие принципы-критерии (например, количество свободных агентов), по которым можно приблизиться к наиболее оптимальному пакетированию?
Если есть возможность выиграть на логическом пакетировании, то надо его применять.
Фактически этот метод сам по себе может давать ускорение в 10-100-1000-10000 раз даже без учета распределенности.
Собственное пакетирование - это внутренний оптимизатор. Каков мехнизм передачи результатов внутренней оптимизации на внешнюю? Чтобы при своем пакетировании иметь такой же результат в итоге, как если бы внутреннего пакетирования не было бы.
Один из вариантов - после пакетного расчета выдать наружу самый лучший результат. Это для задач поиска исключительно наилучших результатов.
А в общем плане - как только включим передачу назад файлов и массивов данных, то станет легче делать пакетные обработчики.
Алгоритмическую оптимизацию никто не отменял. Тогда внутренне пакетирование, действительно, может дать приемущества на порядки.
Но речь шла о совсем простом случае - считывание одних и тех же данных на каждом проходе. Возможно, для мат. расчетов было бы целесообразно ввести возможность единоразового считывания данных. Тогда не надо было бы заморачиваться со своим пакетированием для ускорения этого нюанса.
Но речь шла о совсем простом случае - считывание одних и тех же данных на каждом проходе. Возможно, для мат. расчетов было бы целесообразно ввести возможность единоразового считывания данных. Тогда не надо было бы заморачиваться со своим пакетированием.
Мы же не знаем что именно и как читает программа. Плюс есть явная необходимость полной переинициализации для гарантированной очистки окружения.
Попытка сделать костыль в виде возможности оставить объекты в памяти после перезапуска даст огромный клубок проблем.
Файловый кеш немного спасет, но самое кардинальное - это логическое пакетирование внутри одного вызова.
В общем виде мысль "экономия на моем системном оверхеде при наличии внешнего пакетирования при полном невмешательстве моего кода" не состоятельна. Увы.
При этом мы эффективно боремся со снижением нашего системного оверхеда на каждом из этапов облачной сети.
Мы же не знаем что именно и как читает программа. Плюс есть явная необходимость полной переинициализации для гарантированной очистки окружения.
Перед запуском оптимизации на каждом агенте вы инициализируете вначале окружение - считывание нужного куска истории и т.д. Делаете это один раз. Далее уже все проходы используют считанные данные.
Предлагаю такой же мезанизм и для мат. расчетов. Функция OnInitOptimization().
Еще раз повторюсь, что речь идет не о лени алгоритмически оптимизировать. Ни в коем случае. Алгоритмизация архи-важна. Идет речь лишь о простой задачи единократного считывания входных данных.
Вы же понимаете, что если задачи между разными проходами никак не используют результаты своих вычислений, то алгоритмическая оптимизация для них бессмысленна.
И городить для таких задачи собственное пакетирование только ради того, чтобы оптимизировать этот тривиальный нюанс - громоздко. Проще же через функцию OnInitOptimization().
P.S. Даже если отвлечься от мат. расчетов в сторону опять же фин. рынков, то для создания своего тестера/оптимизатора стратегий, написанного на том же MQL5 (характеристики которого упомянались здесь), было бы очень полезно иметь OnInitOptimization().
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Какие ограничения накладываются на передачу исходных данных?
Сейчас возможности облака позволяют ускорить в тысячи раз довольно простые брут-форс задачи. Например, подбор пароля к RAR-архиву... Т.к. исходные данные присутствуют в небольшом размере и их можно сразу поместить в советник.
Понятно, что также можно поступить и в общем случае, помещая любое количество исходных данных прямо в исполняемый файл...
Но нужно не только отправлять данные, но и получать их в количестве больше, чем одна штука (критерий оптимизации). Например, находится минимум целевой функции, необходимо на выходе получить не только значение этой функции в точке, но и другие ее характеристики (значение производной и другие).
Какие ограничения накладываются на передачу посчитанных данных?
Также некоторые задачи для своего решения требуют создание огромного размера (многие гигабайты) матриц из исходных данных.
Как ведет себя агент, если выделяемой под советник памяти нужно больше, чем имеется свободной оперативной памяти на машине агента? Может имеет смысл в таких случаях отключать на подобных агентах задачу, чтобы освобождать их под более эффективные нужды?
P.S. Многие НИИ выделяют денежные средства на использование ресурсов супер-компьютеров. Цены значительно выше облачных. При этом ускорение вычислений ограничено сверху возможностями супер-компьютера, чего в облачном случае практически нет. Платить $1000 в месяц и более за ускорения в тысячи раз, загружая любого размера облако на 100%, готовы многие.
P.P.S. Хотелось бы, чтобы облако было универсальным вычислительным ресурсом. Где возможность проводить чисто финансовые расчеты, получая исторические данные, было бы только дополнительным бонусом.