Получаем количество десятичных знаков после запятой любых чисел (не только котировок) в обход Digits() на MQL4 и MQL5 - страница 21
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пока в дороге. Можете сами попробовать. Идея в том, чтобы использовать юнионы с массивами структур различной размера, например 10, 100, 1000, 10000...
Эта идея использовалась. При этом
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Получаем количество десятичных знаков после запятой любых чисел (не только котировок) в обход Digits() на MQL4 и MQL5
fxsaber, 2018.12.08 16:25
Пробовал, конечно, разные размеры. По какой-то причине не влияют на результат.
Эта идея использовалась. При этом
В исходнике все видно.Да, просмотрел это. Странно что не влияют.
В исходнике есть строка, отвечающая за размер
Можно это значение менять и смотреть на результат. При значениях больше сотни скорость не растет. Это на самом деле легко объяснить, т.к. копируется по итогу все равно одинаковое количество элементов. А тормоза, связанные с малыми порциями копирования, исключаются.
Боюсь, уже уперлись в максимальную производительность.
Да, согласен.
Я попробовал - тот же самый результат получился, что и у вас в TicksToIntArray_fxsaber4/IntArrayToTicks_fxsaber4
Есть исходники, можно замерить самому.
Ну так замерьте. Я почти уверен, что нет, поэтому не вижу смысла тратить время ни на статью ни на замер.
Боюсь, уже уперлись в максимальную производительность.
Если честно, то я очень удивлен что так близко удалось приблизиться к memcpy. Этого просто не может быть. Что-то не так.
Боюсь, уже уперлись в максимальную производительность.
Я кажется понял очень серьезный Ваш просчет.
В Вашем BANCH выбирается минимальный из 50 абсолютно одинаковых прогонов.
Но компилятор большой умница и лентяй. Он не будет делать одну и ту же работу 50 раз, а оптимизирует код. Поэтому нужно хотя бы массивы менять на каждом проходе. Или вместо 50 поставить 1, но увеличить количество тестов. Тогда результаты будут совсем другие и более объективными.
Когда разница в сравнении с memcpy 40% - это более правдоподобно
Интересно, даст эффект компрессия массива. Массив тиков можно ужать в 10-12 раз. Только вот вопрос - сэкономит ли это результирующее время при отправке и приеме через ресурс.
Я кажется понял очень серьезный Ваш просчет.
В Вашем BANCH выбирается минимальный из 50 абсолютно одинаковых прогонов.
Но компилятор большой умница и лентяй. Он не будет делать одну и ту же работу 50 раз, а оптимизирует код.
Код написан так, что будет делать именно то, что от него хотят. Компилятор не в состоянии повлиять на скорость memcpy, но результаты проходов таковы
цикл из одного прохода
Из 50-ти
Код написан так, что будет делать именно то, что от него хотят. Компилятор не в состоянии повлиять на скорость memcpy, но результаты проходов таковы
цикл из одного прохода
Из 50-ти
Ну так замерьте. Я почти уверен, что нет, поэтому не вижу смысла тратить время ни на статью ни на замер.
Мне не нужно.