Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
На текущем уровне процессоров можно забыть про тормоза double математики. Нет тормозов.
И методы оптимизации переносом в integer уже реально устарели. В разы больше потеряешь на конвертации, чем выиграешь на математике.
С учетом 64 битного кода и нашего компилятора нужно забыть про integer в классе задач, основанном на double вычислениях..
Вот предыдущий пример разбора попыток оптимизации Николая: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332
Компилятор сумел вычисления двух 64 битных double корней из разных выражений объединить в одной 128 битной ассемблерной команде. При работе с double математикой категорически не рекомендуется прыгать/конвертироваться в integer типы. Там на конвертации дикие процессорные(не наши) оверхеды.
ничего не надо округлять
вот тебе скрипт, как наглядный пример.
Запусти сначала с параметрами по умолчанию (со сглаженными окружностями и координатами и размерами типа double)
а потом запусти с параметром typ = not_smoothed_circles (с несглаженными окружностями и координатами и размерами типа int - из класса CCanvas)
Шикарно получилось.
У меня без сглаживания 347 кадров в секунду, а со сглаживанием 97 на канвасе в 2100х550 пикселей.
Для информации, у нас стоит ограничитель частоты апдейтов окна в 500 кадров в секунду. Это показывает, какой производительности можно добиться в графике.
На текущем уровне процессоров можно забыть про тормоза double математики. Нет тормозов.
И методы оптимизации переносом в integer уже реально устарели. В разы больше потеряешь на конвертации, чем выиграешь на математике.
С учетом 64 битного кода и нашего компилятора нужно забыть про integer в классе задач, основанном на double вычислениях..
Вот предыдущий пример разбора попыток оптимизации Николая: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332
Компилятор сумел вычисления двух 64 битных double корней из разных выражений объединить в одной 128 битной ассемблерной команде. При работе с double математикой категорически не рекомендуется прыгать/конвертироваться в integer типы. Там на конвертации дикие процессорные(не наши) оверхеды.
Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.
Не, ну это не морфинг. Морфингом с натяжкой можно это назвать:
А вообще, лень было делать самому настоящий - нашёл в папках примеров.
Морфинг, буквально - умертвление.
Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.
Коню понятно, как говорила Елена Юрьевна.
По мотивам Doom и по совету @fxsaber.
За основу был взят алгоритм с этого сайта с небольшими доработками
Чем картинки делаешь, Николай?
Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.
Нет.
Для начала осознайте, что:
Морфинг, буквально - умертвление.
Не стоит тут это обсуждать, но всё же Морфинг (англ. morphing — трансформация) Уж где ты там мертвецов увидел - трезвей...
Не стоит тут это обсуждать, но всё же Морфинг (англ. morphing — трансформация) Уж где ты там мертвецов увидел - трезвей...
Морфометрический анализ - анализ убитых клеток. Сначала убиваем, после - под микроскоп.
Нет.
В два раза int быстрее double