Podczas optymalizacji kodu zdałem sobie sprawę z następujących kwestii:
>>> from timeit import Timer as T
>>> T(lambda : 1234567890 / 4.0).repeat()
[0.22256922721862793, 0.20560789108276367, 0.20530295372009277]
>>> from __future__ import division
>>> T(lambda : 1234567890 / 4).repeat()
[0.14969301223754883, 0.14155197143554688, 0.14141488075256348]
>>> T(lambda : 1234567890 * 0.25).repeat()
[0.13619112968444824, 0.1281130313873291, 0.12830305099487305]
i również:
>>> from math import sqrt
>>> T(lambda : sqrt(1234567890)).repeat()
[0.2597470283508301, 0.2498021125793457, 0.24994492530822754]
>>> T(lambda : 1234567890 ** 0.5).repeat()
[0.15409398078918457, 0.14059877395629883, 0.14049601554870605]
Zakładam, że ma to związek ze sposobem implementacji Pythona w C, ale zastanawiam się, czy ktoś miałby ochotę wyjaśnić, dlaczego tak jest?
python
c
performance
python-2.7
python-internals
prochowiec
źródło
źródło
Odpowiedzi:
(Dość nieoczekiwany) powód twoich wyników jest taki, że Python wydaje się składać stałe wyrażenia obejmujące mnożenie i potęgowanie zmiennoprzecinkowe, ale nie dzielenie.
math.sqrt()
jest zupełnie inną bestią, ponieważ nie ma dla niej kodu bajtowego i zawiera wywołanie funkcji.W Pythonie 2.6.5 następujący kod:
x1 = 1234567890.0 / 4.0 x2 = 1234567890.0 * 0.25 x3 = 1234567890.0 ** 0.5 x4 = math.sqrt(1234567890.0)
kompiluje się do następujących kodów bajtowych:
# x1 = 1234567890.0 / 4.0 4 0 LOAD_CONST 1 (1234567890.0) 3 LOAD_CONST 2 (4.0) 6 BINARY_DIVIDE 7 STORE_FAST 0 (x1) # x2 = 1234567890.0 * 0.25 5 10 LOAD_CONST 5 (308641972.5) 13 STORE_FAST 1 (x2) # x3 = 1234567890.0 ** 0.5 6 16 LOAD_CONST 6 (35136.418286444619) 19 STORE_FAST 2 (x3) # x4 = math.sqrt(1234567890.0) 7 22 LOAD_GLOBAL 0 (math) 25 LOAD_ATTR 1 (sqrt) 28 LOAD_CONST 1 (1234567890.0) 31 CALL_FUNCTION 1 34 STORE_FAST 3 (x4)
Jak widać, mnożenie i potęgowanie nie zajmuje dużo czasu, ponieważ są one wykonywane podczas kompilacji kodu. Dzielenie trwa dłużej, ponieważ dzieje się to w czasie wykonywania. Pierwiastek kwadratowy jest nie tylko najbardziej kosztowną obliczeniowo operacją z tych czterech, ale także wiąże się z różnymi kosztami narzutów, których nie mają inne (wyszukiwanie atrybutów, wywołanie funkcji itp.).
Jeśli wyeliminujesz efekt ciągłego zwijania, niewiele jest do oddzielenia mnożenia i dzielenia:
In [16]: x = 1234567890.0 In [17]: %timeit x / 4.0 10000000 loops, best of 3: 87.8 ns per loop In [18]: %timeit x * 0.25 10000000 loops, best of 3: 91.6 ns per loop
math.sqrt(x)
jest w rzeczywistości trochę szybszy niżx ** 0.5
, prawdopodobnie dlatego, że jest to szczególny przypadek tego ostatniego i dlatego można go wykonać wydajniej, pomimo kosztów ogólnych:In [19]: %timeit x ** 0.5 1000000 loops, best of 3: 211 ns per loop In [20]: %timeit math.sqrt(x) 10000000 loops, best of 3: 181 ns per loop
edycja 2011-11-16: Zwijanie wyrażeń stałych jest wykonywane przez optymalizator wizjera Pythona. Kod źródłowy (
peephole.c
) zawiera następujący komentarz wyjaśniający, dlaczego dzielenie stałe nie jest zawijane:case BINARY_DIVIDE: /* Cannot fold this operation statically since the result can depend on the run-time presence of the -Qnew flag */ return 0;
-Qnew
Flaga umożliwia podział „prawdziwą” zdefiniowanego w PEP 238 .źródło
/
w Pythonie 3,//
aw Pythonie 2 i 3. Najprawdopodobniej jest to spowodowane faktem, że/
w Pythonie 2 może mieć różne znaczenia. Może po wykonaniu stałego zwijania nie wiadomo jeszcze, czyfrom __future__ import division
jest w efekcie?1./0.
w Pythonie 2.7 nie powoduje,NaN
ale plikZeroDivisionError
.