Очистка массива от заданного (ых) элементов - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
думаю удачно совпали флаги:
http://osinavi.ru/asm/4.php
а для for лишние операторы/сравнения...
Возвращаюсь к непонятой для меня разницы во времени выполнения почти на 100 % одинаковых по логике и количеству проверок и сумм двух циклов:
я уже выше писал - у меня в коде получилось меньше операций сравнения...
-----
из вне-школьных занятий, где-то из 90-х годов:
1) если (условия) A,B,C независимы, то в функцию AND их надо пихать по мере возрастания вероятности, а в функцию OR по мере убывания.
а если зависимы, то их нельзя объединять в одно выражение (то есть делать if (A && B) ).
2) Если есть вложенные циклы A,B то внешним из них должен быть более короткий
3) если внутри цикла есть условие, то по возможности надо делить цикл и выносить условие наружу
я уже выше писал - у меня в коде получилось меньше операций сравнения...
-----
из вне-школьных занятий, где-то из 90-х годов:
1) если (условия) A,B,C независимы, то в функцию AND их надо пихать по мере возрастания вероятности, а в функцию OR по мере убывания.
а если зависимы, то их нельзя объединять в одно выражение (то есть делать if (A && B) ).
2) Если есть вложенные циклы A,B то внешним из них должен быть более короткий
3) если внутри цикла есть условие, то по возможности надо делить цикл и выносить условие наружу
1) наоборот, что Вы и сделали. Особенности исполнения условных операторов в С. Если первое условие в составном операторе AND не исполняется, то зачем проверять все прочие условия. Поэтому, сначала проверяем условие, которое, скорее всего, false.
Хотя, да - так и есть: сортировка по возрастанию вероятности истинности утверждений в составном условии.
1) наоборот, что Вы и сделали. Особенности исполнения условных операторов в С.
может неправильно написал, но , как бы так понятнее для всех сразу объяснить...
A && B && C
AND надо фейлить как можно скорее, чтобы не перебирать все прочие условия. То есть первым ставится тот предикат который вернее обломает исполнение всей дальнейшей цепочки. Оптимизатор за программиста такого не сделает (*) потому что не знает на каких данных исполняется программа
A || B || C
тут наоборот :-) потому чта булева арифметика.. !( (!A)&&(!B)&&(!C) ) (если опять в скобках,знаках не запутался)
*) оптимизирующие компиляторы могут полагаться на то что условия расставлены именно так, и свою внутреннюю кухню строят на этих предположениях
может неправильно написал, но , как бы так понятнее для всех сразу объяснить...
A && B && C
AND надо фейлить как можно скорее, чтобы не перебирать все прочие условия. То есть первым ставится тот предикат который вернее обломает исполнение всей дальнейшей цепочки. Оптимизатор за программиста такого не сделает (*) потому что не знает на каких данных исполняется программа
A || B || C
тут наоборот :-) потому чта булева арифметика.. !( (!A)&&(!B)&&(!C) ) (если опять в скобках,знаках не запутался)
*) оптимизирующие компиляторы могут полагаться на то что условия расставлены именно так, и свою внутреннюю кухню строят на этих предположениях
Согласен полностью.
Возвращаюсь к непонятой для меня разницы во времени выполнения почти на 100 % одинаковых по логике и количеству проверок и сумм двух циклов:
Итак, повторяюсь, почему такой вариант из кода Кузнецова:
работает более чем в два раза быстрее, чем такой, делающий абсолютно тоже самое:
Что за чудеса компилятора?
Неужели для такой конструкции:
компилятор находит какую то особенную ассемблерную команду поиска для процессора? Но ведь внутри стоит дополнительная проверка i<j?
ведь тоже самое через for выполняется заметнее медленнее:
Код демонстрирующего скрипта прилагаю
Вот так часто бывает. Вроде занимаешься какой-то ненужной фигней и выясняешь для себя что-то весьма интересное.
Разработчики, Вы можете глянуть исполняемый код, за счет чего такая разница?
Ведь нужно понимать логику компилятора, чтобы в дальнейшем создавать более оптимальные алгоритмы.
Вообще странная ситуация.Думаю многое зависит от компилятора и машины на какой происходит тестирование.Вот мой результат вашего примера на 32-битной машине
как видим нет ни какого особого приимущества. А вот тест функций удаления из массива из последнего варианта.
при чём иногда при тестировании результаты могут сильно отличатся от предыдущих и не понятно с чем это связано, возможно какая-то специфическая система прерываний при обработке кода у MQL
при тестировании алгоритмов надо брать
* или заранее приготовленные наборы данных (примерно похожие на реально требуемые),
* или делать очень значительное число проходов на ГСЧ,
в тестах:
* чередовать/тасовать очередность тестирования и
* соблюдать паузы и сбрасывать всякие кеши
при тестировании алгоритмов надо брать
* или заранее приготовленные наборы данных (примерно похожие на реально требуемые),
* или делать очень значительное число проходов на ГСЧ,
в тестах:
* чередовать/тасовать очередность тестирования и
* соблюдать паузы и сбрасывать всякие кеши
ну как бы мы используем заранее подготовленные данные. Для теста всех функций используются одни и те же данные. А вот на счёт тасовать/чередовать это да., я заметил разницу если менять очерёдность тестов. А вот как сбрасывать кеши ?
при тестировании алгоритмов надо брать
* или заранее приготовленные наборы данных (примерно похожие на реально требуемые),
* или делать очень значительное число проходов на ГСЧ,
в тестах:
* чередовать/тасовать очередность тестирования и
* соблюдать паузы и сбрасывать всякие кеши
Не надо над людьми издеваться