Я имел преимущество читать другие ответы. Во-первых, такие люди, как я, должны знать причину, по которой мы имеем дело с таким огромным целым числом, заключается в том, что оба Python
и bc
выполняют расширение правой степени ассоциативного возведения в степень, что означает, что это не 6^36
мы оцениваем, а 6^46656
значительно больше. 1
Используя варианты следующих команд, мы можем извлечь среднее значение для конкретного элемента вывода как time
зарезервированного слова, так и команды:
for i in {1..1000}; do (time echo 6^6^6 | bc > /dev/null) 2>&1; done | grep 'rea' | sed -e s/.*m// | awk '{sum += $1} END {print sum / NR}'
for i in {1..1000}; do (/usr/bin/time -v sh -c 'echo 6^6^6 | bc > /dev/null') 2>&1; done | grep 'Use' | sed -e s/.*:// | awk '{sum += $1} END {print sum / NR}'
Можно пойти другим путем и полностью удалить файл из сравнения. Кроме того, мы можем сравнить синхронизацию bc с чем-то вроде dc
команды, поскольку исторически первый является «процессором переднего плана» для второго. Следующие команды были рассчитаны по времени:
echo 6^6^6 | bc
echo 6 6 6 ^ ^ p | dc
echo print 6**6**6 | python2.7
Обратите внимание, что dc
команда является левой ассоциативной для возведения в степень. 2
У нас есть некоторые результаты с time
(bash) для 1000 итераций (в секундах):
0.229678 real bc
0.228348 user bc
0.000569 sys bc
0.23306 real dc
0.231786 user dc
0.000395 sys dc
0.07 real python
0.065907 user python
0.003141 sys python
bc
и dc
предложить сопоставимую производительность в этом контексте.
Менее точные 3 результата из команды /usr/bin/time
GNU time
(точность масштаба здесь недопустима, но результаты аналогичны):
0.2224 user bc
0 sys bc
0.23 Elapsed bc
0.22998 user dc
0 sys dc
0.23 Elapsed dc
0.06008 user python
0 sys python
0.07 Elapsed python
Преимущество /usr/bin/time
заключается в том, что он предлагает -v
опцию, которая дает гораздо больше информации, которая может быть полезна в конечном итоге.
Можно также оценить это внутренне, так сказать с timeit
модулем Python:
python2.7 -m timeit -n 1000 -r 1 'print 6**6**6' | grep 'loops'
1000 loops, best of 1: 55.4 msec per loop
Это немного быстрее, чем мы видели раньше. Давайте попробуем сам переводчик:
>>> import timeit
>>> import sys
>>> import os
>>> T = timeit.Timer("print 6**6**6")
>>> n = int(1000)
>>> f = open(os.devnull, 'w')
>>> sys.stdout = f
>>> t = t.timeit(n)
>>> sys.stdout = sys.__stdout__
>>> print t/n
0.0553743481636
Это самое быстрое, что я видел.
Если мы оценим как меньшее возведение в степень 6^6
, то команда time дает удивительные результаты - используя те же самые for
команды цикла, которые мы использовали, мы теперь имеем:
0.001001 bc real
0.000304 user
0.000554 sys
0.014 python real i.e. 10x more than bc??
0.010432 user
0.002606 sys
Так что с меньшим целым числом bc
вдруг намного быстрее ?? От перезагрузки системы до второго запуска не имеет значения. В то же время, если мы используем timeit
Python, мы получаем:
python2.7 -m timeit -n 100000 -r 1 'print 6**6' | grep loops
100000 loops, best of 1: 0.468 usec per loop
Это микросекунды , а не миллисекунды, так что это не совпадает с гораздо более медленными результатами при использовании for
цикла. Возможно, для дальнейшего тестирования требуются другие инструменты, и, как другие объясняли, здесь есть нечто большее, чем кажется на первый взгляд. Кажется, Python был быстрее в сценарии вопроса, но не ясно, можно ли сделать выводы за этим ...
1. Излишне говорить , что это выходит за рамки чего - то вроде эха арифметического расширения , т.е. echo $((6**6**6))
- bash
также случается правоассоциативной для этого есть 6^6^6 = 6^(6^6)
.
2. Сравните с этим: 6 6 ^ 6 ^ p
.
3. Возможно, команда GNU time предоставляет больше информации при запуске в BSD UNIX (документ информации о времени GNU): большая часть информации, отображаемой в «time», получена из системного вызова «wait3». Числа такие же хорошие, как и те, что возвращены функцией wait3. Многие системы не измеряют все ресурсы, о которых может сообщать «время»; эти ресурсы указаны как ноль. Системы, которые измеряют большинство или все ресурсы, основаны на 4.2 или 4.3BSD. Более поздние выпуски BSD используют другой код управления памятью, который измеряет меньше ресурсов. - В системах, в которых нет вызова «wait3», который возвращает информацию о состоянии, вместо этого используется системный вызов «times». Он предоставляет гораздо меньше информации, чем «wait3», поэтому в «системном времени» этих систем большинство ресурсов указывается как ноль.