Комментарии 11
Чем объяснить, что (на первых рисунках) время для большого массива меньше чем для маленького?
Полагаю, Вы про ситуацию с 30-40 микросекундами. В моём понимании в таком масштабе быстродействия определяющими становятся внутренние процессы в компьютере. С точки зрения пользователя это рандом. Если мы запустим один и тот же код десять раз мы получим десять разных скоростей выполнения, которые могут отличаться в 2-3 раза.
А как тестировали? Надо бы timeit использовать, он встроенный и в нем по умолчанию 10тыс. прогонов усредняются
Тестировали в ручном режиме, да. На более поздних этапах большое количество прогонов сильно ударило бы по времени вычислений. Задача была сравнить порядки скорости вычисления, а для них разница в 2 раза не существенна.
Но в целом Вы правы, для более честного эксперимента стоило бы использовать timeit
Там еще есть 300мс - 2мс или 100мс - 0,8мс. Увеличение времени от размера только на двойном цикле. Если все это накладные расходы то как сравнивать?
p.s. Похоже у вас попутаны мс и мкс...
Я полагаю, мы можем сравнивать с точки зрения потребителя, то есть, собственно, программиста. Разница между 100 микросекундами и 80 микросекундами на практике неразличима. И наверно вывод о выборе инструмента по такой разнице делать не слишком правильно. Другое дело 0.2 секунды и 0.8 миллисекунды...
И да, спасибо, что заметили. На последних двух картинках действительно есть путаница с "сокращениями". Исходные числа в секундах - точные.
Чего-то мне кажется что компилятор раста просто выбросил "фиктивный" цикл полностью.
Вы правы. Код не вставился полностью. Поэтому в том виде, что было, действительно никакой нагрузки второй цикл не давал. Сейчас исправил код - там в фиктивном цикле просто присваивается значение переменной.
Спасибо за внимательность.
Вы, кажется, не поняли. Компилятор при компиляции полностью вырезает внутренний цикл и переменную temp, так как они нигде не используются и не вносят изменений в наблюдаемое поведение программы, потому и результаты точно такие же как и в обычном цикле.
Признаюсь, не знал о такой фишке компилятора. Спасибо, что рассказали.
Это в каком-то смысле также подтверждает выводы статьи о том, что Раст эффективно умеет работать с такими кейсами. Другое дело, что мы не совсем честно оценили его скорость на более реалистичной задаче.
Есть хороший онлайн инструмент просмотра ассемблера для кода: https://godbolt.org/
Если вы закинете туда свой код (не забудьте поставить флаг компиляции для rustc: -O, чтобы убрать отладочные символы), то увидите, что он не компилируется из-за синтаксических ошибок переменной temp там нет -- она оптимизировалась. Собственно все предупреждения компилятора типа "something ... never used" указывают на места, которые будут выкинуты на этапе компиляции.
Python на максималках: расширения на языках Rust и Cython