Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А какая часть моего кода конкретно интересует? У меня зависимость от файлов разных много.
Проблема у меня сейчас только в записи и чтения буфера за 1 тик тестера, а для проверки достаточно:
Запуск скриптом:
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) Device #0 = Cypress
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) OpenCL: GPU device 'Cypress' selected
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) build log =
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) Размер буфера в байтах =240
Запуск экспертом в тестере с 2013.01.09 по 2013.10.10 на M5 с "OHLC на М1":
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 Device #0 = Cypress
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 OpenCL: GPU device 'Cypress' selected
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 build log =
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 Размер буфера в байтах =240
2013.10.30 19:04:55 Core 1 EURUSD,M5: 1108637 ticks (55953 bars) generated within 192443 ms (total bars in history 131439, total time 192521 ms)
2013.10.30 19:04:55 Core 1 294 Mb memory used
Обратите внимание, что в тестере только 1 девайс.
Если
//CLBufferRead(hbuffer[1], price);
тогда
Если необходимо производить расчёты на данных OHLC, то обязательно нужно делать экономную запись, т.е. заранее создать буфер большего размера и при поступлении новых данных дозаписывать только эти новые данные, сообщая ядру новые начало и размер буфера.
Даже если удаться оптимизировать передачу OHLC (будем через CLSetKernelArg последний бар передавать), то всё равно на чтении буфера для результатов вылетаем:
Ну кто ж вам мешает-то. Возьмите и напишите что-нибудь реальное, чтобы не сказка была. Но попробуйте найти пример, чтобы ускорение таки было. Это и есть самое сложное.
Если речь о моих статьях... ну дык я ж ликбез писал. Да и умножение матриц - вполне полезная операция.
P.S. Кстати, если CPU - Intel, то эмуляция на нем x86 ядрах гораздо быстрее, чем на CPU конкурента. Это если в пересчете на ядро.
HD5850: в принципе вполне приличная карта, но вот современные карты получше - не только за счет большего количества мух, но и за счет оптимизаций под OpenCL. Например, значительно уменьшено время доступа к глобальной памяти.
P.P.S. OpenCL - не панацея, а реальное средство, позволяющее в некоторых редких случаях существенно ускоряться. А в остальных случаях, не очень удобных, ускорение не такое впечатляющее - если оно есть.
Эх... статьи о повышению скорости с помощью OpenCL на GPU оказались сказкой, потому что не реальные задачи в них описаны :(
Не так. Сказка - что "любой алгоритм можно ускорить на OpenCL". Не любой.
В первой ветке по OpenCL даже вполне описаны критерии, которым должен обладать алгоритм, чтобы иметь потенциал ocl-ускорения.
Успехов.
Претензии не к скорости вычисления - тут ускорение в 2 раза (0,02 ms vs 0,05 ms)
Претензия, что в статьях нет инфы:
Наверно я первый, кто захотел ускорить прохождение теста за счет GPU, начитавшись обещаний...
Мои посты еще раз перечитай.
Главный критерий: выполнение кода MQL в "стиле OpenCL" за 1 тик должно превышать время = Количество_Буферов * 0,35300 ms
Чтобы узнать скорость алгоритма на MQL с точностью до микросекунд (1000 микросекунд = 1 миллисекунда) придется прогнать несколько раз в тестере и Общее_Время / Количество_Тиков (верхний мой пост).
Если бы не буферная задержка, то мой код проходил тест за ~30 секунд - это ~2 раза быстрее MQL в "стиле OpenCL" (55 секунд) и в ~11 раз быстрее обычного кода (320 секунд).
Какие там еще критерии?
Судя по опыту вашего общения с OpenCL, вы уже должны были понять, что тупо напрямую ускоряется далеко не каждый алгоритм. Тут одна из главных проблем - минимизация обращений к глобальной памяти.
Кстати, мне сейчас надо решать аналогичную проблему с произвольным доступом к глобальной памяти девайса (слишком част этот произвольный доступ, а это ить охрененный overhead). Решу обязательно, как только включу моск.
Тестер не выбирает CPU для OpenCL - об этом вообще ни где не сообщается!
Пишите в сервисдеск и обосновывайте необходимость такой фичи.
Если тестер не используется, то это уже сделано (это моя заявка). А на тестере я еще не проверял.
Вам писали уже, что тупо напрямую ускоряется далеко не каждый алгоритм. Тут моск включать надо, и одна из главных проблем - минимизация обращений к глобальной памяти.
Ну и чо, мне сейчас надо решать аналогичную задачу с произвольным доступом к глобальной памяти девайса (слишком част этот произвольный доступ). Решу обязательно, как только включу моск.
Это Вам пора мозг включать, потому что 0,35300 ms относится именно к clEnqueue[Read/Write]Buffer(), а не к обращению глобальной памяти внутри kernel.
Второе решается оптимизацией самого kernel, а вот первое - железное ограничение и мозг тут не поможет.