Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну, и че тогда бред не проверенный запостил?
Наверно я всё таки единственный, кто OpenCL в тестере заюзал... попытался...
Ну, и че тогда бред не проверенный запостил?
Наверно я всё таки единственный, кто OpenCL в тестере заюзал... попытался...
Это не бред, а удовлетворенная заявка.
Еще раз: пиши в сервисдеск и обосновывай то, что хочешь. Не сможешь обосновать - твоя проблема.
На момент написания этих статей разговор об использовании OpenCL в тестере еще всерьез не начинался. Заявка относится именно к этому времени.
Мои посты еще раз перечитай.
Главный критерий: выполнение кода MQL в "стиле OpenCL" за 1 тик должно превышать время = Количество_Буферов * 0,35300 ms
Чтобы узнать скорость алгоритма на MQL с точностью до микросекунд (1000 микросекунд = 1 миллисекунда) придется прогнать несколько раз в тестере и Общее_Время / Количество_Тиков (верхний мой пост).
Если бы не буферная задержка, то мой код проходил тест за ~30 секунд - это ~2 раза быстрее MQL в "стиле OpenCL" (55 секунд) и в ~11 раз быстрее обычного кода (320 секунд).
Какие там еще критерии?
Ну вот щас всё брошу и буду перечитывать. Я ж тебя не прошу все мои посты на форуме касающиеся OpnCL перечитывать.. :) A там меж тем все основные критерии описываются и обсуждаются.
Основной критерий - отношение t_alg/t_mem, где t_alg- алгоритмически оптимизированное время расчёта кернел-алгоритма, t_mem - время обращения к удалённой (*) памяти. Чем больше этот критерий, тем больше перспективность ускорения с помощью OpenCL. Другими словами чем "тяжелей" расчёты и чем меньше пересылки массивов в устройство и обратно, тем больше перспективность.
(*) удалённая память = все виды "нерегистровой" памяти (регистровая очень быстрая), например (1) глобальная память девайса гораздо медленнее регистровой, но гораздо быстрее чем (2) внешняя для устройства память (ОЗУ процессора).
Это не бред, а удовлетворенная заявка.
Еще раз: пиши в сервисдеск и обосновывай то, что хочешь. Не сможешь обосновать - твоя проблема.
Еще раз: баг #865549 от 2013.10.17 23:17 и разработчики извещены, но врядли что-то исправят. Наверно это ограничение кто-то из них специально добавил, чтобы не подвесить весь процессор при оптимизации.
Но в статьях об этом не слова!
Этой команды в реализации OpenCL for MQL5 нет. О чем разговор?
Эх... а еще статьи по OpenCL выдаешь...
Чтоб ты знал: clEnqueueReadBuffer = CLBufferRead и clEnqueueWriteBuffer = CLBufferWrite, а еще они вызываются синхронно.
Познание начинается отсюда
Народ, прежде что-то дальше доказывать подумайте: о трёх постах начиная отсюда и конкретно о
А то Вы на оптимизации самого kernel зациклились, а мои посты о буферах.
Я давно знаю, что реализация OpenCL for MQL5 - это только обертка над истинным API. И во второй статье, кстати, писал, что не хватает возможности установки размера рабочей группы (work-group). Сделал заявку в сервисдеск, и через некоторое время это сделали.
Я также знаю, что CLBuffer[Read/Write] - аналоги clEnqueue[Read/Write]Buffer, но эти функции совсем не идентичны: у них разные синтаксисы.
Но мне непонятно, зачем ты продолжаешь говорить о функциях clEnqueueXXX, которых в OpenCL for MQL5 таки нет.
Попробую врубиться, чего же ты хочешь.
Это Вам пора мозг включать, потому что 0,35300 ms относится именно к clEnqueue[Read/Write]Buffer(), а не к обращению глобальной памяти внутри kernel.
Второе решается оптимизацией самого kernel, а вот первое - железное ограничение и мозг тут не поможет.
Но мне непонятно, зачем ты продолжаешь говорить о функциях clEnqueueXXX, которых в OpenCL for MQL5 таки нет.
Да нет там разницы. Там наверняка вот такая обертка:
Так что про синтаксис можешь тоже не выдумывать. А что 3 аргумент = CL_TRUE - это уже подтверждено.
Mathemat:
Претензия именно к писателям статей, что об этом самом важном ограничении нет практических данных! (Не было, пока я не протестировал.)
Претензия именно к писателям статей, что об этом самом важном ограничении нет практических данных! (Не было, пока я не протестировал.)
А ты не читай больше статей. И претензий не будет. ;)
--
Ну чего ты прикопался? Как можно в статье привести неизвестные данные? То что лаг предачи данных из/в устройство большой и с ним надо считаться говорилось на форуме не раз. Конкретные цифры зависят от конкретной аппаратуры. Ну протестил у себя и молодец. Люди вона (включая меня) иногда тестовый код выкладывают, чтоб оценить возможности и ограничения различной аппаратуры. Просят других людей поделиться результатами, люди часто делаятся (за что им респекты), заодно все видят статистику и что как работает в каких комбинациях. Потом кто-то с ориентиром на результаты перезакупает железо или меняет подходы к написанию кода. А ты блиннн... Чего хочешь-то? Ну напиши жалобу в Спортлото, может от этого твой код быстрей заработает...
:)
Вообще-то я на https://www.mql5.com/ru/forum/13715/page5#comment_646513 уже всё закончил, но авторы статей сами захотели что-то еще доказать.
Нет в ваших статьях конкретной и очень важной инфы, поэтому они не закончены и описывают нереальные задачи.
Можете не добавлять инфу в статьи, но глупо делать вид, что именно эти цифры ничего не значат.
Я не понял скрытый смысл скрипта/советника, который ты выложил, Roffild. В коде есть, мягко говоря, непонятки.
- Где прагма cl_khr_fp64? Она ж нужна при вычислениях с double в кернеле.
- Почему в функции OnTick() находится вот этот кусок кода, который вообще можно вынести в начальную инициализацию, вычислив единожды?
- Почему размер глобальной задачи равен 240 байтам? Он должен быть гораздо больше, чтобы получить какой-то выигрыш от OpenCL. Ну хотя бы в миллион раз - если прикинуть на глазок.
- Почему глобальная задача для получения размера локальной делится на число units? И CPU, и GPU позволяют делить глобальную задачу на гораздо большее число подзадач. А units в твоем случае - это просто количество SIMD engines.
Вот у меня, скажем, число units в видеокарте равно 28 (Radeon HD7950). Но это число не делит нацело 240. Это означает, что существенная часть вычислений может быть непараллельной.
Число шейдеров у меня - 1792. У тебя - 1440. Вот примерно на это число лучше и делить глобальную задачу, чтобы нормально загрузить карту. Но придется правильно вычислить размер глобальной задачи. (А лучше не делить, а умножать.)
А что твоя карта все это время считает - вообще непонятно.
Короче: что должен делать твой код?