"Новый нейронный" - проект Open Source движка нейронной сети для платформы MetaTrader 5. - страница 58
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
???
Не важно.
Мне важно, я хочу развиваться, слышать разные мнения, делать выводы.
ЗЫ Андрей не воспринимай всё близко, всегда правым быть не получится, на то и опенсорсе проект чтоб спорить, доказывать.
GPU Cuda дело мощное. Был у меня код, ктоторый на 16-и интеловских тредах (4-ядерном процессоре) выполнялся 2-3 часа. А на 300+ CUDA ядрах бежал ту же дистанцию за 10 минут, что впечетляло. Но разработка кудовского кода была очень сложной: нужно вручную разбивать все вычисления в коде на пареллельные потоки, оптимизировать память (к сожелению её у кудовских ядер мало). Мне такое было не под силу - помог умный программист. Я до сих пор пугаюсь его кода и продолжаю все имзенения делать в своем оригинальном (неразпараллеленном) коде. Выработал у себя такое мнение: если алгоритм устойчивый, то можно его оптимизировать и переносить на ГПУ при помощи грамотного программиста, программистам-самоучкам как я такое не под силу. Если сразу начинать с ГПУшного кода для нобъезженного алгоритма, то объездка займёт долгое время. Сам всегда начинаю с простого хотя неоптимального кода, который сам могу понять. И только после получения ожидаемых результатов, начинаю его оптимизировать. Раздолбай я, а не программист :)
GPU Cuda дело мощное. Был у меня код, ктоторый на 16-и интеловских тредах (4-ядерном процессоре) выполнялся 2-3 часа. А на 300+ CUDA ядрах бежал ту же дистанцию за 10 минут, что впечетляло. Но разработка кудовского кода была очень сложной: нужно вручную разбивать все вычисления в коде на пареллельные потоки, оптимизировать память (к сожелению её у кудовских ядер мало). Мне такое было не под силу - помог умный программист. Я до сих пор пугаюсь его кода и продолжаю все имзенения делать в своем оригинальном (неразпараллеленном) коде. Выработал у себя такое мнение: если алгоритм устойчивый, то можно его оптимизировать и переносить на ГПУ при помощи грамотного программиста, программистам-самоучкам как я такое не под силу. Если сразу начинать с ГПУшного кода для нобъезженного алгоритма, то объездка займёт долгое время. Сам всегда начинаю с простого хотя неоптимального кода, который сам могу понять. И только после получения ожидаемых результатов, начинаю его оптимизировать. Раздолбай я, а не программист :)
Поэтому нам бы нужна консультация специалиста в области вычислений на GPU. yu-sha и JavaDev, ау!
Интересуют следующие вопросы:
1. На что следует в первую очередь обратить внимание, при закладке возможностей (пока только возможностей, не реализации) вычисления проекта (или отдельных его модулей) на GPU, что бы избежать гемороя по переделке в будущем?
2. Каковы ограничения по памяти ядер GPU? Возможно ли в принципе разместить целиком исполнительный код по отдельному прогону по истории в памяти (десятки и сотни тысяч баров)?
Пока такие, общие вопросы. Более детальные, я так понимаю, возникнут позднее.
Поэтому нам бы нужна консультация специалиста в области вычислений на GPU. yu-sha и JavaDev, ау!
Интересуют следующие вопросы:
1. На что следует в первую очередь обратить внимание, при закладке возможностей (пока только возможностей, не реализации) вычисления проекта (или отдельных его модулей) на GPU, что бы избежать гемороя по переделке в будущем?
2. Каковы ограничения по памяти ядер GPU? Возможно ли в принципе разместить целиком исполнительный код по отдельному прогону по истории в памяти (десятки и сотни тысяч баров)?
Пока такие, общие вопросы. Более детальные, я так понимаю, возникнут позднее.
А зачем вообще связываться с кудой в проекте предназначенном для широкого использования? У одних юзеров одна куда, у других другая, а у третьих вообще куды нет. У меня например куды нет на моем рабочем ноутбуке. Код той же сети будет очень различен в зависимости от количества ядер в куде и памяти. Лучше поначалу написать этот движок сетей для обычного интеловского процессора чтобы все могли пользоваться, а потом оптимизировать для куд если в этом есть смысл. Кстати, движок лучше создавать таким образом чтобы работал в облаке. Я с вычислениями в облаке слабо знаком. Там куды вообще есть?
А зачем вообще связываться с кудой в проекте предназначенном для широкого использования? У одних юзеров одна куда, у других другая, а у третьих вообще куды нет. У меня например куды нет на моем рабочем ноутбуке. Код той же сети будет очень различен в зависимости от количества ядер в куде и памяти. Лучше поначалу написать этот движок сетей для обычного интеловского процессора чтобы все могли пользоваться, а потом оптимизировать для куд если в этом есть смысл. Кстати, движок лучше создавать таким образом чтобы работал в облаке. Я с вычислениями в облаке слабо знаком. Там куды вообще есть?
MQ обещали поддержку в MQL5 не CUDA (только видеокарты от nVidia), а OpenCL. OpenCL может работать на любом оборудовании, имеющем многоядерные процессоры, это и CPU, и GPU (AMD и nVidia и intel). Так что, проект с поддержкой вычислений и на CPU и на GPU будет работать у всех.
Раз MQL5 будет поддерживать OpenCL, значит и агенты клауда будут поддерживать вычисления на GPU.
Urain:
всегда правым быть не получится, на то и опенсорсе проект чтоб спорить, доказывать.
Поэтому нам бы нужна консультация специалиста в области вычислений на GPU. yu-sha и JavaDev, ау!
Интересуют следующие вопросы:
1. На что следует в первую очередь обратить внимание, при закладке возможностей (пока только возможностей, не реализации) вычисления проекта (или отдельных его модулей) на GPU, что бы избежать гемороя по переделке в будущем?
2. Каковы ограничения по памяти ядер GPU? Возможно ли в принципе разместить целиком исполнительный код по отдельному прогону по истории в памяти (десятки и сотни тысяч баров)?
Пока такие, общие вопросы. Более детальные, я так понимаю, возникнут позднее.
Главные моменты:
1) GPU нужны только при обучении
2) Существенное увеличение производительности достигается за счет параллельного вычисления значений нейронов в одном слое и, что более важно!, - за счет одновременного прогона сотен сетей
Максимальная разбивка проекта на автономные компоненты - вот на что следует обратить внимание
DDR памяти на GPU более чем достаточно для того, чтобы хранить историю сотен тысяч баров
Память ядра сильно ограничена (30-50 КБайт). Пряморукость программирования решает и этот вопрос - оно того стоит, поскольку память чипа работает на частоте ядра и доступ к ней стоит 0 тактов. Там есть еще конфликты банков ядерной памяти, они тоже обходятся.
Есть неприятный момент, связанный с особенностью Windows - ресет драйверов, если один прогон длится >~ 5 секунд
Поэтому максимум, чего удалось добиться: обучение 100-200 сетей из ~ 100 нейронов на 100 тыс баров истории
При такой (максимальной) конфигурации получаем скорость оптимизации ~ 20-30 прогонов в секунду на GPU GTX 460