Признаюсь, не знал о такой фишке компилятора. Спасибо, что рассказали.
Это в каком-то смысле также подтверждает выводы статьи о том, что Раст эффективно умеет работать с такими кейсами. Другое дело, что мы не совсем честно оценили его скорость на более реалистичной задаче.
Я полагаю, мы можем сравнивать с точки зрения потребителя, то есть, собственно, программиста. Разница между 100 микросекундами и 80 микросекундами на практике неразличима. И наверно вывод о выборе инструмента по такой разнице делать не слишком правильно. Другое дело 0.2 секунды и 0.8 миллисекунды...
И да, спасибо, что заметили. На последних двух картинках действительно есть путаница с "сокращениями". Исходные числа в секундах - точные.
Тестировали в ручном режиме, да. На более поздних этапах большое количество прогонов сильно ударило бы по времени вычислений. Задача была сравнить порядки скорости вычисления, а для них разница в 2 раза не существенна.
Но в целом Вы правы, для более честного эксперимента стоило бы использовать timeit
Полагаю, Вы про ситуацию с 30-40 микросекундами. В моём понимании в таком масштабе быстродействия определяющими становятся внутренние процессы в компьютере. С точки зрения пользователя это рандом. Если мы запустим один и тот же код десять раз мы получим десять разных скоростей выполнения, которые могут отличаться в 2-3 раза.
Вы правы. Код не вставился полностью. Поэтому в том виде, что было, действительно никакой нагрузки второй цикл не давал. Сейчас исправил код - там в фиктивном цикле просто присваивается значение переменной.
Признаюсь, не знал о такой фишке компилятора. Спасибо, что рассказали.
Это в каком-то смысле также подтверждает выводы статьи о том, что Раст эффективно умеет работать с такими кейсами. Другое дело, что мы не совсем честно оценили его скорость на более реалистичной задаче.
Я полагаю, мы можем сравнивать с точки зрения потребителя, то есть, собственно, программиста. Разница между 100 микросекундами и 80 микросекундами на практике неразличима. И наверно вывод о выборе инструмента по такой разнице делать не слишком правильно. Другое дело 0.2 секунды и 0.8 миллисекунды...
И да, спасибо, что заметили. На последних двух картинках действительно есть путаница с "сокращениями". Исходные числа в секундах - точные.
Тестировали в ручном режиме, да. На более поздних этапах большое количество прогонов сильно ударило бы по времени вычислений. Задача была сравнить порядки скорости вычисления, а для них разница в 2 раза не существенна.
Но в целом Вы правы, для более честного эксперимента стоило бы использовать timeit
Полагаю, Вы про ситуацию с 30-40 микросекундами. В моём понимании в таком масштабе быстродействия определяющими становятся внутренние процессы в компьютере. С точки зрения пользователя это рандом. Если мы запустим один и тот же код десять раз мы получим десять разных скоростей выполнения, которые могут отличаться в 2-3 раза.
Вы правы. Код не вставился полностью. Поэтому в том виде, что было, действительно никакой нагрузки второй цикл не давал. Сейчас исправил код - там в фиктивном цикле просто присваивается значение переменной.
Спасибо за внимательность.