Ошибки, баги, вопросы - страница 2878
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
какой вариант преобразований будет быстрее работать при оптимизации
Это же будет вызывать только один раз на весь проход. Поэтому без разницы.
Это же будет вызывать только один раз на весь проход. Поэтому без разницы.
так то да... но собираюсь на пару дней комп запустить на оптимизацию, хочется каким-нибудь способом замерить производительность ..... хотя подозреваю что вариант 1 будет эффективнее, не будет 100500 раз копирования в массивы
так то да... но собираюсь на пару дней комп запустить на оптимизацию, хочется каким-нибудь способом замерить производительность ..... хотя подозреваю что вариант 1 будет эффективнее, не будет 100500 раз копирования в массивы
union это не копирование в массивы, это разная интерпретация того же участка памяти. так что скорее всего 2-й вариант быстрее, но, как заметили выше, это неважно.
так то да... но собираюсь на пару дней комп запустить на оптимизацию, хочется каким-нибудь способом замерить производительность ..... хотя подозреваю что вариант 1 будет эффективнее, не будет 100500 раз копирования в массивы
есть старый способ измерение скорости
в стиле
for (int i=0; i< 1000000; i++) {наш код1}....
for (int i=0; i< 1000000; i++) {наш код2}....
Юнион не так быстр, как кажется. Ставлю на первый.
тоже ставлю на первый! бинайрные операторы быстрее оператора if в разы, хотя во втором его и нету
проверил:
2020.10.15 21:48:01.401 SpeedTst (EURUSD,H1) tst 1 : : loops=10000000000 ms=10864370
2020.10.15 21:48:12.264 SpeedTst (EURUSD,H1) tst 2 : : loops=10000000000 ms=10862287
не значительная разница, высока вероятность, что если поменять тесты местами, то результаты будут наоборот
в общем не критично
не значительная разница, высока вероятность, что если поменять тесты местами, то результаты будут наоборот
высока вероятность что компилятор сгенерировал для обоих случаев одинаковый код. в этом случае просто выбрать то что субъективно больше нравится
проверил:
2020.10.15 21:48:01.401 SpeedTst (EURUSD,H1) tst 1 : : loops=10000000000 ms=10864370
2020.10.15 21:48:12.264 SpeedTst (EURUSD,H1) tst 2 : : loops=10000000000 ms=10862287
не значительная разница, высока вероятность, что если поменять тесты местами, то результаты будут наоборот
в общем не критично
Тут вроде скрипт который демонстрирует что время создание случайных чисел может быть неравномерным, и много чего зависит от обьема создаваемых переменных)))
А нужный нам код в таком количестве повторений у меня занимает 0 ms
ответа так и нету
либо оптимизатор кода че-то лишнего вырезаетТут вроде скрипт который демонстрирует что время создание случайных чисел может быть неравномерным
нет rand() это обычная функция, она всегда одинаково работает
а вот если при тестировании скорости работы инициализировать константами, то тесты будут "разгоняться" при выполнении - оптимизация кода в MQL во время выполнения не плохо работает
в общем это проверенно не однократно
и много чего зависит от обьема создаваемых переменных)))
конечно, выделение памяти это затратно по времени выполнения, я это уже проверял, тестировал динамически созданные обьекты ( указатель new ) и и просто обьекты в локальной области видимости, при тесте 100500 раз набегает время на new + delete
вопрос в целом был, по причине того, что в тестере в глобальной видимости для переменных память выделяется один раз, а не каждый проход - но мне нужны массивы uint , поэтому тестировал таким скриптом, а не как написал в первый раз
А нужный нам код в таком количестве повторений у меня занимает 0 ms
ответа так и нету
либо оптимизатор кода че-то лишнего вырезаетмоим скриптом тестировали? - или не дождались конца теста и прервали , или переполнили ulong - первый параметр макроса это 10^ count
высока вероятность что компилятор сгенерировал для обоих случаев одинаковый код. в этом случае просто выбрать то что субъективно больше нравится
да, может и так
тут в общем в чем вопрос то был - читал неоднократно, что современные процессоры за счет оптимизации конвейера команд могут за один такт выполнять больше одной элементарной операции .... много обла-бла-бла... и суть, что арифметические команды процессор выполняет за непредсказуемое количество тактов
а вот операции ветвления и выделения памяти очень плохо оптимизируются процессором, поэтому не ищите оптимизации в упрощении арифметики, старайтесь писать максимально линейный код с минимум ветвлений, да и переменные лучше объявлять и присваивать им значения непосредственно перед расчетами, что позволяет конвейеру команд и предсказание выборки кэша оптимизировать этот код
т.е. скорее всего выборка значений элементов в массиве (адресация) тоже не критична будет по скорости - тут думал будет выигрыш сдвига против union, оказалось вообще нет разницы