Canvas - это круто! - страница 18
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Похоже, здесь непонимание, о чем говорил. Речь шла о примере частной задачи Тестера, где целочисленные цены могут дать выигрышь в определенных ситуациях. Универсальный случай не имелся в виду. Именно поэтому свой Тестер, на который дал ссылку выше, реализован на даблах, т.к. универсальный.
Не могу согласиться в 100% случаев.
Вы сделали утверждение:
Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.
Оно абсолютно ошибочно при попытке реализовать на практике. Ошибочно на 100% в практике.
Поэтому не надо переходить в теорию или замену темы. Тема "текущий тестер можно ускорить при переводе в целочисленный". И тема на 100% ошибочна без исключений.
Вы сделали утверждение:
Оно абсолютно ошибочно при попытке реализовать на практике. Ошибочно на 100% в практике.
Поэтому не надо переходить в теорию или замену темы. Тема "текущий тестер можно ускорить при переводе в целочисленный". И тема на 100% ошибочна без исключений.
Прошу заметить, что это единственное мое утверждение, где слово Тестер изначально взято мною в кавычки. Вы не правильно поняли тему, что поднял.
Это надстройка над Вашим Тестером, которая без изменения кода любого советника (с любыми индикаторами) делает полноценный проход со всеми сделками и профитами. Но делает это быстрее, чем штатный Тестер. Все воспроизводимые доказательства приводил. Люди с ресурса проверяли эти утверждения.
Покажите.
А потом докажите, что дело в переходе на целочисленный механизм, а не в том, что мы неэффективно реализовали тот или иной механизм по недосмотру.
Если речь об влиянии перерасчета базы открытых позиций, то там реально есть тормоза, которые мы в ближайшие дни исправим.Прошу заметить, что это единственное мое утверждение, где слово Тестер изначально взято мною в кавычки. Вы не правильно поняли тему, что поднял.
Я все правильно понял.
И правильно раскрыл тему с неприятными для вас деталями. Если вы думаете, что мы не просчитывали целочисленный тестер, то сильно ошибаетесь.
Покажите.
Показываю.
А потом докажите, что дело в переходе на целочисленный механизм, а не в том, что мы неэффективно реализовали тот или иной механизм по недосмотру.
Отказался от целочисленных Тестеров из-за их не универсальности. Они были быстрее, но минусов было больше, чем плюсов. Однако, как явление, могут существовать. Virtual-работа - на даблах.
Было бы здорово!
Показываю.
Вот этот случай?
https://www.mql5.com/ru/forum/285631/page107#comment_10271917
Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.
Я сравнивал быстродейтвие double и int в этих двух одинаковых скриптах:
На удивление вариант с преобладающим double оказался даже чуть быстрее на моем процессоре.
Шикарно получилось.
У меня без сглаживания 347 кадров в секунду, а со сглаживанием 97 на канвасе в 2100х550 пикселей.
Для информации, у нас стоит ограничитель частоты апдейтов окна в 500 кадров в секунду. Это показывает, какой производительности можно добиться в графике.
Спасибо.
На самом деле со сглаживанием double окружности медленнее оригинальных без сглаживания int окружностей где-то на 20 %. У меня 300 против 250 кадров в секунду.
Просто по видимому Вы замеряли сглаженные окружности с тенями, а тень окружности гораздо прожорливее самой окружности. Тень можно отключить параметром draw a shadow? = false.
Я сравнивал быстродейтвие double и int в этих двух одинаковых скриптах:
На удивление вариант с преобладающим double оказался даже чуть быстрее на моем процессоре.
Бойтесь как огня массовых конвертаций вида (int)double или (double)int и вообще смешения int+double в мат операциях.
Это дает дичайший оверхед в процессоре - просто такая дорогая ассемблерная команда. Если считаете в double, продолжайте в нем считать и не переключайтесь в integer типы.
Команды вида cvtsi2sd/cvttsd2si очень долгие. Небольшая наводка в статье "Самая медленная инструкция x86", злодей номер 2.
The Intel® 64 and IA-32 Architectures Optimization Reference Manual says that cost of the cvttsd2si instruction is 5 latency (see Appendix C-16). cvtsi2sd, depending on your architecture, has latency varying from 1 on Silvermont to more like 7-16 on several other architectures.
Agner Fog's instruction tables have more accurate/sensible numbers, like 5-cycle latency for cvtsi2sd on Silvermont (with 1 per 2 clock throughput), or 4c latency on Haswell, with one per clock throughput (if you avoid the dependency on the destination register from merging with the old upper half, like gcc usually does with pxor xmm0,xmm0).
Спасибо.
На самом деле со сглаживанием double окружности медленнее оригинальных без сглаживания int окружностей где-то на 20 %. У меня 300 против 250 кадров в секунду.
Просто по видимому Вы замеряли сглаженные окружности с тенями, а тень окружности гораздо прожорливее самой окружности. Тень можно отключить параметром draw a shadow? = false.
Оказывается, я смотрел частоту генерации полотна, а не частоту вывода.
Это разные числа, кратно отличающиеся.