![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Большое спасибо!
У вас расчеты в double идут? Тогда результат особенно впечатляющий.Дельное замечание. Действительно, в одном месте был float вместо double:
Чтобы был double, нужно исправить на
Кроме того, можно избавиться от последней строки (аналог макроса XRGB), если применить uchar4 вместо uint для аргумента *buf. Попробуйте так:
Это действительно впечатляет! Fps в 1.5 раза выше, чем на шейдерах.
Спасибо, код работает, производительность не упала, только в последней строке альфа канал перенес в конец:
Это действительно впечатляет! Fps в 1.5 раза выше, чем на шейдерах.
Спасибо, код работает, производительность не упала, только в последней строке альфа канал перенес в конец:
В данной реализации производительность сильно зависит от количества центров (N). По-хорошему, надо бы избавиться от цикла в кернеле, но тогда S1 и S2 придётся делать целочисленными. Нужно посмотреть, насколько велик разброс их значений, может получится на что-то умножить без особого греха. И тогда можно перевести цикл в третье измерение, что теоретически даст прирост производительности при больших значениях N.
У меня на HD 7950 на full-hd мониторе получается 80-90 fps при N=128.
В данной реализации производительность сильно зависит от количества центров (N). По-хорошему, надо бы избавиться от цикла в кернеле, но тогда S1 и S2 придётся делать целочисленными. Нужно посмотреть, насколько велик разброс их значений, может получится на что-то умножить без особого греха. И тогда можно перевести цикл в третье измерение, что теоретически даст прирост производительности при больших значениях N.
У меня на HD 7950 на full-hd мониторе получается 80-90 fps при N=128.
На моей 750ti 11 fps. Я спеки для карточек нашел:
По логике, переход на float может поднять fps сразу в 4 раза на amd и в 32 на nvidia.
Сделал копию OCL версии. Я в шоке от результата. При 1600 центрах не смог загрузить видяху больше 85%.
Оптимизация с предрасчетом h не влияет, но оставил с ней. Все расчеты в float, не вижу смысла использовать double, т.к. все функции все равно возвращают float.
Некоторые выводы.
1) Предрасчет h не повлиял.
2) При избавлении от if разницы не заметил
3) Так медленнее,
чем так
казалось бы...
4) Не удается разгрузить проц, то есть про скальперские стаканы и т.п. можно забыть.
Некоторые выводы.
1) Предрасчет h не повлиял.
2) При избавлении от if разницы не заметил
3) Так медленнее,
чем так
казалось бы...
4) Не удается разгрузить проц, то есть про скальперские стаканы и т.п. можно забыть.
На МТ5, скальперские стаканы запросто в одном потоке могут работать, без OCL и не перегружать процессор. Конечно, это не значит, что он не нужен. Просто к сведению.
Если использовать класс CCanvas при построении стакана, то, нагрузка при работе будет соразмерна площади стакана. Т.е. - чем больше окно стакана, тем выше нагрузка, ведь перерисовывается ВЕСЬ канвас, а не отдельные, изменившиеся части. Однако, превратив ячейки стакана в самостоятельные элементы, их можно обновлять независимо от остальной площади канваса, в разы снизив время перерисовки и вызываемую ею нагрузку на процессор.
На МТ5, скальперские стаканы запросто в одном потоке могут работать, без OCL и не перегружать процессор. Конечно, это не значит, что он не нужен. Просто к сведению.
Если использовать класс CCanvas при построении стакана, то, нагрузка при работе будет соразмерна площади стакана. Т.е. - чем больше окно стакана, тем выше нагрузка, ведь перерисовывается ВЕСЬ канвас, а не отдельные, изменившиеся части. Однако, превратив ячейки стакана в самостоятельные элементы, их можно обновлять независимо от остальной площади канваса, в разы снизив время перерисовки и вызываемую ею нагрузку на процессор.
4 пункт под вопросом. В примере Remnant3D проц почти не грузится.
4 пункт под вопросом. В примере Remnant3D проц почти не грузится.
Это проверено. Проц на МТ5 при обычной динамики стакана почти не грузится, если перерисовывать отдельные ячейки в которых изменилось значение.
Напротив, если на событии каждого приходящего значения рисовать ВСЮ площадь канваса - процессор будет сильно напрягаться.
Разница в количестве переинициализируемых значений в массиве пикселей. Нужно выборочное обновление отдельных областей и проблем с нагрузкой не будет.
Это проверено. Проц на МТ5 при обычной динамики стакана почти не грузится, если перерисовывать отдельные ячейки в которых изменилось значение.
Напротив, если на событии каждого приходящего значения рисовать ВСЮ площадь канваса - процессор будет сильно напрягаться.
Разница в количестве переинициализируемых значений в массиве пикселей. Нужно выборочное обновление отдельных областей и проблем с нагрузкой не будет.
В том и прикол, что в Remnant3D канвас на весь экран и проц не грузит.