Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
про оператор [] уже был разговор, что он как-то слишком медленный для C++ подобного языка. Не думал что прям настолько что ArrayCopy его рвет как тузик грелку.
про инкремент внутри оператора отдельный вопрос.
Чтож вы себя исправили а меня выкинули ? нехорошо
Ни кого не выкидывал. Что скачал скачал, то и вернул )))
Ни кого не выкидывал. Что скачал скачал, то и вернул )))
ну так вы скачали 11-й, мой -12-й(ниже), а вы исправили 11-й и вернули как 13-й.
про оператор [] уже был разговор, что он как-то слишком медленный для C++ подобного языка. Не думал что прям настолько что ArrayCopy его рвет как тузик грелку.
про инкремент внутри оператора отдельный вопрос.
Да тут даже лишние операции ни к чему. Если идет прогон по циклу. Незачем сравнивать при копировании текущего элемента, вышел он за пределы, или нет. Будет в пределах. Да и что-то складывать смысла, так-же нет и тянуть еще одну переменную. Если по умолчанию, есть i.
Короче так мелочевка всякая. Чисто для инфы написал
ну так вы скачали 11-й, мой -12-й(ниже), а вы исправили 11-й и вернули как 13-й.
Не обратил внимание. Заменил файл.
ещё набросал в этот беспощадный конкурс :-)
Опять-же не проверял :-) должно по идее работать..
Закоментил тесты содержащие ошибки (Semko и Pavlov) .
Спасибо, исправил.
ещё набросал в этот беспощадный конкурс :-)
Опять-же не проверял :-) должно по идее работать..
включил, но с первым вариантом что-то не так
Возвращаюсь к непонятой для меня разницы во времени выполнения почти на 100 % одинаковых по логике и количеству проверок и сумм двух циклов:
Итак, повторяюсь, почему такой вариант из кода Кузнецова:
работает более чем в два раза быстрее, чем такой, делающий абсолютно тоже самое:
Что за чудеса компилятора?
Неужели для такой конструкции:
while(arr[i]!=x && i<j) i++;
компилятор находит какую то особенную ассемблерную команду поиска для процессора? Но ведь внутри стоит дополнительная проверка i<j?
ведь тоже самое через for выполняется заметнее медленнее:
Код демонстрирующего скрипта прилагаю
Вот так часто бывает. Вроде занимаешься какой-то ненужной фигней и выясняешь для себя что-то весьма интересное.
Разработчики, Вы можете глянуть исполняемый код, за счет чего такая разница?
Ведь нужно понимать логику компилятора, чтобы в дальнейшем создавать более оптимальные алгоритмы.
Интересное наблюдение. и ради интереса прогнал код
Возвращаюсь к непонятой для меня разницы во времени выполнения почти на 100 % одинаковых по логике и количеству проверок и сумм двух циклов:
Итак, повторяюсь, почему такой вариант из кода Кузнецова:
работает более чем в два раза быстрее, чем такой, делающий абсолютно тоже самое:
Что за чудеса компилятора?
Неужели для такой конструкции:
компилятор находит какую то особенную ассемблерную команду поиска для процессора? Но ведь внутри стоит дополнительная проверка i<j?
ведь тоже самое через for выполняется заметнее медленнее:
Код демонстрирующего скрипта прилагаю
Вот так часто бывает. Вроде занимаешься какой-то ненужной фигней и выясняешь для себя что-то весьма интересное.
Разработчики, Вы можете глянуть исполняемый код, за счет чего такая разница?
Ведь нужно понимать логику компилятора, чтобы в дальнейшем создавать более оптимальные алгоритмы.
думаю удачно совпали флаги:
http://osinavi.ru/asm/4.php
а для for лишние операторы/сравнения...