OpenCl и инструменты для него. Отзывы и впечатления. - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Подозреваю, что Mischek месяц назад кричал именно об этом.
Область применения OpenCL вижу либо при тяжелом тестировании, либо при очень интенсивных распараллеливаемых расчетах на лету.
Пока надобности в этом нет (все тяжелые расчеты у меня в init() индюкатора), но взял на заметку.
Алексей, у меня - та-же беда: норовлю что-то в init перетянуть, а уж после - в реал тайм :)
Мозги повернуты на процедурный язык. ООП - желанный, но - не родной.
Для фанатичных четвёрочников не заглядывающих на mql5.com : OpenCL: внутренние тесты реализации в MQL5
Спасибо, лично я вот не видел. Только не всё так просто.
К тому же Ринат путает народ: OpenCL 1.0 может прекрасно работать с double float, там это предусмотрено "как общедоступная опция", которую поддержали все производители - НО ПРОСТО НЕ ДЛЯ ВСЕХ СВОИХ СТАРЫХ КАРТ.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Optional Double Precision and Half Floating Point
OpenCL 1.0 adds support for double precision and half floating-point as optional extensions. The double data type must confirm to the IEEE-754 double precision storage format.
An application that wants to use double will need to include the #pragma OPENCL EXTENSION cl_khr_fp64 : enable directive before any double precision data type is declared in the kernel code. This will extended the list of built-in vector and scalar data types to include the following:....."
Он может работать и в тестере, но в эксперте OpenCL 1.0 работать не будет, и не потому что как говорит Ринат "там нет double float", а именно потому - как я выше сказал - из-за отсутствия safe threading в OpenCL 1.0 и из-за чехарды с потоками в МТ4-5.
В OpenCL (и в CUDA) вообще много путанного. Что Вы хотите? Ведь железячники-радиотехники взялись менять концепцию программирования. У них же железячный склад ума.
Проблемка будет ещё и с так называемом "выбором ПЛАТФОРМЫ": прога, то есть МТ, или DLL эксперта, или эксперт - ДОЛЖНЫ, просто обязаны ВРУЧНУЮ выбрать платформу (AMD, Nvidia, Intel), которых на компе может быть несколько и разных, на которой и будет запущен кернел OpenCL, а потом ещё вручную выбрать DEVICE, если на компе стоит Multi-GPU. Авто-выбора платформы в OpenCL пока нет. Ринат говорит о "авто-выборе мощнейшей", но я не знаю, как это. В показанном там примере выбора платформы и выбора device (GPU, CPU) нет.
К тому же автоматического распараллеливания OpenCL заданий на несколько GPU или на GPU+CPU в стандарте пока ещё нет. Скажем так : AMD в некоторых версиях своих драйверов/SDK делала такую вот авто-диспетчеризацию, но там были проблемы, и AMD эту штуку пока выключила.
Итого: для разработки и включения OpenCL программ к/в МТ4-5 нужны некоторые ручные усилия, и поэтому автоматом, или "перекомпиляцией с опцией" это не получится. Что в свою очередь чревато множеством затыков при реальной работе. Это будет тонкая работа и, что важно, я позволю себе повториться, к сожалению это ЖЕЛЕЗО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, что неправильно. Отладка параллельных программ для CUDA или OpenCL оказались намного более сложным делом, чем предполагали железячники-революционеры. Nvidia даже отменила свою осеннюю-2011 конференцию по CUDA - из-за проблем с драйверами и множеством жалоб на затыки в отладке. Ну вот добавили они в последний Toolkit ещё 1000 новых функций - и что теперь с этим делать, если у простого народа даже простейшая программа не идёт или идёт с затыками? Ведь они даже половину работы внутреннего механизма OpenCL или CUDA в описательных инструментах не указали.
Скорость GPU (в Гигафлопсах) подвисшей из-за драйвера или совместимости программ видео-карты равна нулю.
Спасибо, лично я вот не видел. Только не всё так просто.
....Да дело в общем-то не в этом. Писать в процедурном стиле можно и на пятере.
joo: И, меня обескуражил такой факт, ахтунг! - скрипт MQL4 вызывающий dll работает быстрее, чем скрипт MQL5 с той же dll...
А вот это настораживает.
Взяли бы и сделали нативную поддержку OMP в MQL5. Будет для кодера просто и сердито, и никаких dll писать не надо.
А этот рой пчел, сделанных на недоделанном языке железячного программирования... как-то не очень пока вдохновляет. Ну да, стократное ускорение в отдельных случаях - это здорово, но с точки зрения культуры программирования это шаг назад.
В OpenCL (и в CUDA) вообще много путанного. Что Вы хотите? Ведь железячники-радиотехники взялись менять концепцию программирования. У них же железячный склад ума.
Проблемка будет ещё и с так называемом "выбором ПЛАТФОРМЫ": прога, то есть МТ, или DLL эксперта, или эксперт - ДОЛЖНЫ, просто обязаны ВРУЧНУЮ выбрать платформу (AMD, Nvidia, Intel), которых на компе может быть несколько и разных, на которой и будет запущен кернел OpenCL, а потом ещё вручную выбрать DEVICE, если на компе стоит Multi-GPU. Авто-выбора платформы в OpenCL пока нет. Ринат говорит о "авто-выборе мощнейшей", но я не знаю, как это. В показанном там примере выбора платформы и выбора device (GPU, CPU) нет.
К тому же автоматического распараллеливания OpenCL заданий на несколько GPU или на GPU+CPU в стандарте пока ещё нет. Скажем так : AMD в некоторых версиях своих драйверов/SDK делала такую вот авто-диспетчеризацию, но там были проблемы, и AMD эту штуку пока выключила.
Итого: для разработки и включения OpenCL программ к/в МТ4-5 нужны некоторые ручные усилия, и поэтому автоматом, или "перекомпиляцией с опцией" это не получится. Что в свою очередь чревато множеством затыков при реальной работе. Это будет тонкая работа и, что важно, я позволю себе повториться, к сожалению это ЖЕЛЕЗО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, что неправильно. Отладка параллельных программ для CUDA или OpenCL оказались намного более сложным делом, чем предполагали железячники-революционеры. Nvidia даже отменила свою осеннюю-2011 конференцию по CUDA - из-за проблем с драйверами и множеством жалоб на затыки в отладке. Ну вот добавили они в последний Toolkit ещё 1000 новых функций - и что теперь с этим делать, если у простого народа даже простейшая программа не идёт или идёт с затыками? Ведь они даже половину работы внутреннего механизма OpenCL или CUDA в описательных инструментах не указали.
Скорость GPU (в Гигафлопсах) подвисшей из-за драйвера или совместимости программ видео-карты равна нулю.
Да дело в общем-то не в этом. Писать в процедурном стиле можно и на пятере.
А вот это настораживает.
Взяли бы и сделали нативную поддержку OMP в MQL5. Просто и сердито, и никаких dll писать не надо.
А этот рой пчел, сделанных на недоделанном языке железячного программирования... как-то не очень пока вдохновляет. Ну да, стократное ускорение в отдельных случаях - это здорово, но с точки зрения культуры программирования это шаг назад.
Я тоже встречался с фактами когда mql4 работает быстрее чем MQL5. Проявляется это чаще всего в оптимизированных прогером мат.операциях.
Но думаю это не есть основная проблема, выходя на OpenCL MQ стали на дорогу которая идёт параллельно основной дороги программирования, может пока для этого и требуется отступить, но в перспективе развития компьютерной техники мы увидим комплексные масштабируемые системы, где уже от кода будет зависеть используются ли последовательная обработка или параллельная.
Так что дорога вполне верная. Хотя на сегодняшний день, не так уж много алгоритмов требующих реализующих параллельный подход, но это скорее от того что математическая мысль не имела аппаратуры для реализации параллельных расчётов, а отсюда и не было потребности создавать такие алгоритмы.
Алексей, задумайся только над одним фактом, все математические открытия были сделаны 200-300 лет назад, последние 100 лет математическая мысль просто шлифовала то что есть. И лишь открытие НС сформировала запрос на параллельные расчёты. Следующие 100 лет появятся существенно параллельные алгоритмы. И ты в том числе можешь изобрести один из них.
Я тоже встречался с фактами когда mql4 работает быстрее чем MQL5. Проявляется это чаще всего в оптимизированных прогером мат.операциях.
Но думаю это не есть основная проблема, выходя на OpenCL MQ стали на дорогу которая идёт параллельно основной дороги программирования, может пока для этого и требуется отступить, но в перспективе развития компьютерной техники мы увидим комплексные масштабируемые системы, где уже от кода будет зависеть используются ли последовательная обработка или параллельная.
Так что дорога вполне верная. Хотя на сегодняшний день, не так уж много алгоритмов требующих реализующих параллельный подход, но это скорее от того что математическая мысль не имела аппаратуры для реализации параллельных расчётов, а отсюда и не было потребности создавать такие алгоритмы.
Алексей, задумайся только над одним фактом, все математические открытия были сделаны 200-300 лет назад, последние 100 лет математическая мысль просто шлифовала то что есть. И лишь открытие НС сформировала запрос на параллельные расчёты. Следующие 100 лет появятся существенно параллельные алгоритмы. И ты в том числе можешь изобрести один из них.
Нет, всё-таки ты не совсем безнадёжен. :)
Привет.
MQ молодцы, не побоялись связываться с таким геморроем (для них), как введение поддержки расчетов на GPU. Геморрой, в первую очередь, связан с тем, что введение принципиально новых технологий (любых) снижает на первых парах надёжность и отказоустойчивость платформы в целом. Но они прекрасно понимают, что именно за параллельными вычислениями будущее и им рано или поздно пришлось бы что то делать в этом направлении (первый шаг уже был сделан - облако).
PS Привет, Николай. Почему пропал? - чиркани в личку.
Это не факт, т.к. это не так. Качественное развитие математики не прерывалось никогда.
Да и параллельные расчеты нужны далеко не только НС, есть и более приземленные задачи - скажем, кодирование видео или рендеринг.
Но общий вектор движения MQ, конечно, не может не обнадеживать.