OpenCL: реальные задачи - страница 6

Новый комментарий
 
Mathemat: А на тестере я еще не проверял.

Ну, и че тогда бред не проверенный запостил?

Наверно я всё таки единственный, кто OpenCL в тестере заюзал... попытался...

 
Roffild:

Ну, и че тогда бред не проверенный запостил?

Наверно я всё таки единственный, кто OpenCL в тестере заюзал... попытался...

Это не бред, а удовлетворенная заявка.

Еще раз: пиши в сервисдеск и обосновывай то, что хочешь. Не сможешь обосновать - твоя проблема.

На момент написания этих статей разговор об использовании OpenCL в тестере еще всерьез не начинался. Заявка относится именно к этому времени.

Это Вам пора мозг включать, потому что 0,35300 ms относится именно к clEnqueue[Read/Write]Buffer(), а не к обращению глобальной памяти внутри kernel.
Этой команды в реализации OpenCL for MQL5 нет. О чем разговор?
 
Roffild:

Мои посты еще раз перечитай.

Главный критерий: выполнение кода 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) внешняя для устройства память (ОЗУ процессора).

OpenCL: от наивного кодирования - к более осмысленному
OpenCL: от наивного кодирования - к более осмысленному
  • 2012.06.05
  • Sceptic Philozoff
  • www.mql5.com
В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
 
Mathemat:

Это не бред, а удовлетворенная заявка.

Еще раз: пиши в сервисдеск и обосновывай то, что хочешь. Не сможешь обосновать - твоя проблема.

Еще раз: баг #865549 от 2013.10.17 23:17 и разработчики извещены, но врядли что-то исправят. Наверно это ограничение кто-то из них специально добавил, чтобы не подвесить весь процессор при оптимизации.

Но в статьях об этом не слова!

Mathemat:
Это Вам пора мозг включать, потому что 0,35300 ms относится именно к clEnqueue[Read/Write]Buffer(), а не к обращению глобальной памяти внутри kernel.

Этой команды в реализации OpenCL for MQL5 нет. О чем разговор?

Эх... а еще статьи по OpenCL выдаешь...

Чтоб ты знал: clEnqueueReadBuffer = CLBufferRead и clEnqueueWriteBuffer = CLBufferWrite, а еще они вызываются синхронно.

Познание начинается отсюда

MetaDriver: Основной критерий - отношение t_alg/t_mem, где t_alg- алгоритмически оптимизированное время расчёта кернел-алгоритма, t_mem - время обращения к удалённой (*) памяти. Чем больше этот критерий, тем больше перспективность ускорения с помощью OpenCL.  Другими словами чем "тяжелей" расчёты и чем меньше пересылки массивов в устройство и обратно, тем больше перспективность.
Это критерий оптимизации выполнения только. Про скорость передачи самих буферов до моих постов примерных чисел не было.
 

Народ, прежде что-то дальше доказывать подумайте: о трёх постах начиная отсюда и конкретно о

mql5: Конкретно в данном примере преимущество использования OpenCL съедают накладные расходы копирования буферов.


А то Вы на оптимизации самого kernel зациклились, а мои посты о буферах.

 
Roffild: Чтоб ты знал: clEnqueueReadBuffer = CLBufferRead и clEnqueueWriteBuffer = CLBufferWrite, а еще они вызываются синхронно.

Я давно знаю, что реализация OpenCL for MQL5 - это только обертка над истинным API. И во второй статье, кстати, писал, что не хватает возможности установки размера рабочей группы (work-group). Сделал заявку в сервисдеск, и через некоторое время это сделали.

Я также знаю, что CLBuffer[Read/Write] - аналоги clEnqueue[Read/Write]Buffer, но эти функции совсем не идентичны: у них разные синтаксисы.

Но мне непонятно, зачем ты продолжаешь говорить о функциях clEnqueueXXX, которых в OpenCL for MQL5 таки нет.

Попробую врубиться, чего же ты хочешь.

Roffild:

Это Вам пора мозг включать, потому что 0,35300 ms относится именно к clEnqueue[Read/Write]Buffer(), а не к обращению глобальной памяти внутри kernel.

Второе решается оптимизацией самого kernel, а вот первое - железное ограничение и мозг тут не поможет.

Хорошо. К кому претензии? К производителю видеокарты?
 
Mathemat: Я также знаю, что CLBuffer[Read/Write] - аналоги clEnqueue[Read/Write]Buffer, но эти функции совсем не идентичны: у них разные синтаксисы.

Но мне непонятно, зачем ты продолжаешь говорить о функциях clEnqueueXXX, которых в OpenCL for MQL5 таки нет.

Да нет там разницы. Там наверняка вот такая обертка:

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

Так что про синтаксис можешь тоже не выдумывать. А что 3 аргумент = CL_TRUE - это уже подтверждено.

Mathemat:

Второе решается оптимизацией самого kernel, а вот первое - железное ограничение и мозг тут не поможет.
Хорошо. К кому претензии? К производителю видеокарты?

Претензия именно к писателям статей, что об этом самом важном ограничении нет практических данных! (Не было, пока я не протестировал.)

 
Roffild:

Претензия именно к писателям статей, что об этом самом важном ограничении нет практических данных! (Не было, пока я не протестировал.)

А ты не читай больше статей.  И претензий не будет. ;)

--

Ну чего ты прикопался?  Как можно в статье привести неизвестные данные?  То что лаг предачи данных из/в устройство большой и с ним надо считаться говорилось на форуме не раз.  Конкретные цифры зависят от конкретной аппаратуры.  Ну протестил у себя и молодец. Люди вона (включая меня) иногда тестовый код выкладывают, чтоб оценить возможности и ограничения различной аппаратуры. Просят других людей поделиться результатами, люди часто делаятся (за что им респекты), заодно все видят статистику и что как работает в каких комбинациях. Потом кто-то с ориентиром на результаты перезакупает железо или меняет подходы к написанию кода.  А ты блиннн... Чего хочешь-то?  Ну напиши жалобу в Спортлото, может от этого твой код быстрей заработает...

:)

 

Вообще-то я на https://www.mql5.com/ru/forum/13715/page5#comment_646513 уже всё закончил, но авторы статей сами захотели что-то еще доказать.

Нет в ваших статьях конкретной и очень важной инфы, поэтому они не закончены и описывают нереальные задачи.

Можете не добавлять инфу в статьи, но глупо делать вид, что именно эти цифры ничего не значат.

OpenCL: реальные задачи
OpenCL: реальные задачи
  • www.mql5.com
Так что же может дать OpenCL трейдерам?
 

Я не понял скрытый смысл скрипта/советника, который ты выложил, Roffild. В коде есть, мягко говоря, непонятки.

- Где прагма cl_khr_fp64? Она ж нужна при вычислениях с double в кернеле.

- Почему в функции OnTick() находится вот этот кусок кода, который вообще можно вынести в начальную инициализацию, вычислив единожды?

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- Почему размер глобальной задачи равен 240 байтам? Он должен быть гораздо больше, чтобы получить какой-то выигрыш от OpenCL. Ну хотя бы в миллион раз - если прикинуть на глазок.

- Почему глобальная задача для получения размера локальной делится на число units? И CPU, и GPU позволяют делить глобальную задачу на гораздо большее число подзадач. А units в твоем случае - это просто количество SIMD engines.

Вот у меня, скажем, число units в видеокарте равно 28 (Radeon HD7950). Но это число не делит нацело 240. Это означает, что существенная часть вычислений может быть непараллельной.

Число шейдеров у меня - 1792. У тебя - 1440. Вот примерно на это число лучше и делить глобальную задачу, чтобы нормально загрузить карту. Но придется правильно вычислить размер глобальной задачи. (А лучше не делить, а умножать.)

А что твоя карта все это время считает - вообще непонятно.

Короче: что должен делать твой код?

12345678
Новый комментарий
Причина обращения: