OpenCl и инструменты для него. Отзывы и впечатления. - страница 28
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Придет через пару лет - напомним об этой ветке.
Лично для меня эта ветка оказалась весьма полезной - даже тогда, когда топикстартер начал стращать мой неокрепший дух ужасами пониженной точности расчетов.
Режим оптимизации на МТ5 при включенном генетическом алгоритме очень медленный. Я сделал советника на МТ4 оттестировал и оптимизировал. Время на оптимизацию не превышает 5 минут на двуядернике (ясень пень, что в МТ4 задействовано всего одно ядро, но при этом другие задачи уже не мешаются, т.к. они могут выполняться на втором ядре). Переписал того же самого советника под МТ5. Поставил на оптимизацию. Время оптимизации более часа, а точнее почти 2 часа. Разница есть?
Разницы теперь нет.
Вернее, сейчас MetaTrader 5 вырывается вперед даже при тестировании по ценам открытия: Сравнение скорости тестирования в MetaTrader 4 и MetaTrader 5
Как и обещали, упростили режим тестирования по открытию баров и сделали скоростной режим.
Ну вот и прошло два годика.
Работает версия советника на CUDA. Под МТ4. Пока только в режиме тестирования. Пока что не удаётся получить обещанного от nVidia ускорения расчётов.
Две проблемы здесь:
1. сама nVidia, которая преувеличивает скорость переделки программ, или вообще НЕПРАВИЛЬНО готовит свою документацию, или в корне меняет некоторые существенные аспекты программирования.
2. Параллелизация алгоритмов под GPU занимает намного больше времени, чем предполагалось. Когда приступал к переносу программы с DLL на CUDA-DLL, исходя из своего 20+ лет опыта на языке Це полагал, что обещания nVidia надо разделить на 3, а приводимое ими время переноса алгоритмов умножить эдак на 3.
Но оказалось, что общее правило здесь такое: все обещания nVidia надо разделить на ДЕСЯТЬ, а предполагаемое время переноса программ с Си на CUDA умножить на 10.
Примечание: если Вы разобрались в принципах работы ускорителя на GPU, то Вы можете перенести алгоритм с Си на CUDA НЕДЕЛИ ЗА ТРИ. Причём можете сделать это напрямую - просто чтобы проверить билд. То есть Ваша прога будет исполняться только ОДНИМ ИЗ сотен или ТЫСЯЧИ маленьких процессоров в видео-карте. Это работает примерно в 70 (семдесят) раз МЕДЛЕННЕЕ, чем на центральном проце. Да, медленно, но работает.
Затем Вы можете при значительно бОльших усилиях начать паралелли-зировать Вашу программу. Это работает ужЕ в 4-5 раза медленнее или всего в 2-3 раза быстрее чем на центральном проце.
А вот глобально переделать Ваш АЛГОРИТМ, чтобы он исполнялся ПАЧКАМИ, повторяю ПАЧКАМИ, а не последовательно как учат во всех унитетах в мире - вот это задачка не из лёгких.
Уточняю - распараллелить по принципу Multithreading обычный последовательный алгоритм - это трудно, но не необычно. Это одно дело. Вы получаете аналогичным образом на GPU ускорение в 5-10 раз. А вот переделать последовательный алгоритм в пачковый (у меня нет лучшего слова в лексиконе), чтобы загрузить сотни и тысячи процессоров GPU и получить обещанное nVidia ускорение в 100 раз - вот это может быть проблемкой.
Но и она решаема. Это просто вопрос времени.
Но тут ещё Крым, бендеровцы и прочее ....
3. Со стороны MetaTrader-4 при написании программы DLL для CUDA проблем нет.
Проблем-кой является коренное несогласие software-разработчиков nVidia (2500 человек) с моделью multithreading, принятой в MetaTrader-4-5. Причём эту кАнцЭпцию Нвидия в корне поменяла при переходе c версии CUDA 3.2 на версию 4.0+. Причём если Вы начнёте их спрашивать, а почему было так (как Метатрейдере-4 и в сотнях других многопоточных программах), а стало эдак, то в ответ Вы от них услышите только что "Вы в корне не поняли нашу кАнцЭпцию".
Где-то я ужЕ это слышал.... причём недавно.....
4. Переводить свежий алгоритм с Си на CUDA намного легче, чем с Си сразу на универсальный OpenCL, поэтому рекомендую такой путь. Тем более, что вот буквально сегодня nVidia должна вроде представить официально CUDA-6, в которой теоретически на новых GPU серии Maxwell и под некоторыми ОСями можно будет существенно сократить объём программирования - за счёт унификации памяти и выкидывания операций пересылки между CPU и GPU.
Ну?
И чё?
Никому это совсем не интересно?
За год ни одного вопроса или поста.
А вот Нвидии это интересно: почитала она мои жалобы на этом и других форумах, собрала наверное свой худсовет, потёрли они там со всех сторон, - и решили, что трейдеры- тоже люди, и что торговый терминал - это тоже программа, взяли и ввели в последней недавней версии CUDA специальный ключ для компилятора - для создания сильно multithreaded программулек на CUDA.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
строка типа
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
К сожалению, даже Xeon Phi не взлетел. А уж он то более близок к обычному программированию.
Кому нужна мощность в универсальных расчетах, теперь легко может ее получить без особого напряга на мультипроцессорных системах общего назначения. Количество ядер в интеловых процессорах растет достаточно быстро.
Например, у наших серверов по 40 ядер, у меня даже рабочий компьютер с 20 ядрами и DDR4 памятью. Сервак на ксеонах в 40 ядер по 3Ghz однозначно уделывает низкочастотные Xeon Phi с 56 и больше ядрами, не требуя переписи ни одной строки кода.
Кому нужна мощность в универсальных расчетах, теперь легко может ее получить без особого напряга на мультипроцессорных системах общего назначения. Количество ядер в интеловых процессорах растет достаточно быстро.
Например, у наших серверов по 40 ядер, у меня даже рабочий компьютер с 20 ядрами и DDR4 памятью. Сервак на ксеонах в 40 ядер по 3Ghz однозначно уделывает низкочастотные Xeon Phi с 56 и больше ядрами, не требуя переписи ни одной строки кода.
Вы слегка заблуждаетесь (2 раза. Оба.). В принципе я тоже так думал раньше, особенно приступая к GPU программированию.
(1). "Мощность в универсальных расчётах" на хост-CPU можно легко получить ТОЛЬКО для простейших алгоритмов. Именно в этом то и затык для большинства программистов для OpenMP и для GPU. Видеокарт с CUDA продано сотни миллионов, а программ для неё - всего около 300. Для финансов - всего около 7-8 (не считая сборников бесполезных библиотек).
Вот жеж полный список на сайте nVidia:
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Нашего вот первого в мире коммерчески-доступного советника с CUDA-ускорением для торгового терминала MT4 там *пока* нет.).
Этот список не меняется ужЕ несколько лет.
Почему? Да потому что сложный адаптивный алгоритм, который легко складывается из кусочков на хост-CPU, оказывается мало запрограммировать, его надо ещё СЛОЖИТЬ. А это не такое простое дело из-за :
а). особенностей и ограничений CUDA-OpenCL модели GPU (кернелы разного размера надо запускать последовательно).
б). любые пересылки данных по шине PCI между GPU и хост-процессором убивают весь выигрыш по скорости. А в сложных адаптивных алгоритмах без них не обойтись.
(2). "не требуя переписи ни одной строки кода" - это тоже только для простых алгоритмов. Ситуация ухудшается тем, что OpenMP - как реальная альтернатива GPU - работает загадочно, то есть иногда работает, а иногда выдаёт мусор. Это ведь иллюзия, что просто добавлением прагма-строчки в одном месте алгоритм сразу вот так вот распараллелится. Это далеко не так. В сложном алгоритме между данными и параллельными потоками возникают такие неожиданные взаимосвязи, что без построения графа не обойтись.
Совсем другое дело GPU. Там работы сначала больше, НО программа работает ВСЕГДА ПРАВИЛЬНО, в смысле синхронизации. Более того, прога пере-писанная для CUDA (даже без написания кернелов) переводится на OpenMP ДЕЙСТВИТЕЛЬНО одной строкой прагмы - и ЭТО действительно работает. Только после этого переводить её на OpenMP ужЕ нет никакого смысла - намного перспективнее и надёжнее дописать кернелы для CUDA-OpenCL. Удивительно, но кернелы для CUDA GPU получаются короткими, понятными и надёжными.
Ну и с точки зрения абсолютной скорости и надёжности - у хост-CPU нет никаких шансов против GPU.
=Финансовые рынки и форекс в частности являются СИЛЬНО сжатой версией огромных процессов по всему земному шару.
=Поэтому аглоритм для прогнозирования цены не может быть простым. Поэтому в настоящее время он должен быть адаптивным и образно говоря статистическим.
=Поэтому без имитационного моделирования и адаптивной обратной связи в таком хорошем алгоритме никуда.
=Поэтому если для целей выставления ордеров хост-CPU ещё может сгодиться, ( то есть его скорости пока хватает), то для тестирования и оптимизации без GPU уже сейчас работать практически невозможно.
Вы заявили, что я неправ дважды, а потом под видом доказательства выдали совершенно постороннее.
Я прав в следующем (что было заявлено сразу):
OpenMP я не упоминал вообще. С моей точки зрения, OpenMP - это "серебрянная пуля для слабаков". Если ты бьешься за реальную производительность, выкинь глупости с OpenMP и пиши руками изначально правильный/нативный многопоточный код, профилируй его и доводи до максимума.
Вы сами доказали, что нет достаточного программ для GPU вычислений. Большая часть программ для GPU - это как раз простейшие случаи, включая взломщики паролей и глупые майнеры (игры не обсуждаем).
Мое мнение в том, что CPU и базовая инфраструктура эволюционируют достаточно быстро и в реальности перегоняют GPU по реальной производительности в прикладных реальных приложениях. 3-4 года назад можно было верить в потенциал GPU, но сейчас стало все ясно.
Вы заявили, что я неправ дважды, а потом под видом доказательства выдали совершенно постороннее.
Я прав в следующем (что было заявлено сразу):
OpenMP я не упоминал вообще. С моей точки зрения, OpenMP - это "серебрянная пуля для слабаков". Если ты бьешься за реальную производительность, выкинь глупости с OpenMP и пиши руками изначально правильный/нативный многопоточный код, профилируй его и доводи до максимума.
Вы сами доказали, что нет достаточного программ для GPU вычислений. Большая часть программ для GPU - это как раз простейшие случаи, включая взломщики паролей и глупые майнеры (игры не обсуждаем).
Мое мнение в том, что CPU и базовая инфраструктура эволюционируют достаточно быстро и в реальности перегоняют GPU по реальной производительности в прикладных реальных приложениях. 3-4 года назад можно было верить в потенциал GPU, но сейчас стало все ясно.
1. Экстраполируя скорость прироста ядер с хост-CPU, вряд ли в ближайшие годы их количество достигнет 3000 ядер как СЕГОДНЯ у хорошей видео-карты. И каждое ядро видео-карты ведь работает примерно на частоте 1ГГц. Так что тягаться с GPU хост-процессор не сможет. Но это при условии, что есть хорошая программа, которая способна не только и не просто загрузить работой эти 3000 ядра, но и ОБОЙТИ все подводные камни сегодняшней железячной архитектуры GPU. И скорость видео GDDR5 памяти на средней видеокарте на сегодня порядка 150 ГБайт/сек. Всем типам DDR4 (25 GB/sec) памяти туда ещё пилить и пилить.
Куда тут хост-процессору тягаться со свими 40-60 ядрами хоть даже на 4ГГц и 25 Гб/сек памяти?
2. Всякие экзотики типа Phi не имеют нужной поддержки и универсальности как у видео-карты. Поэтому и умерли.
3. Насчёт необходимости прямого программирования многопотоков - это да, согласен с Вами, но это тяжёлый путь. Написать сложный НОВЫЙ адаптивный алгоритм СРАЗУ в много-поточной версии - это очень трудно. А тут же надо работать так сказать эволюционно. И потом, не мне Вам рассказывать как нехорошо Windows управляет многопотоками, когда их становится действительно много (задержки там всякие). Поэтому даже в ОС и придумали так называемые фиберы - упрощённые потоки.
Вывод: дешевле, перспективнее и надёжнее, чем GPU нет ничего.