(Дещо несподіваною) причиною ваших результатів є те, що Python, здається, складає постійні вирази, що передбачають множення з плаваючою точкою та піднесення до степені, але не ділення. math.sqrt()
- це зовсім інший звір, оскільки для нього немає байт-коду, і він включає виклик функції.
На Python 2.6.5 такий код:
x1 = 1234567890.0 / 4.0
x2 = 1234567890.0 * 0.25
x3 = 1234567890.0 ** 0.5
x4 = math.sqrt(1234567890.0)
компілюється до таких байт-кодів:
4 0 LOAD_CONST 1 (1234567890.0)
3 LOAD_CONST 2 (4.0)
6 BINARY_DIVIDE
7 STORE_FAST 0 (x1)
5 10 LOAD_CONST 5 (308641972.5)
13 STORE_FAST 1 (x2)
6 16 LOAD_CONST 6 (35136.418286444619)
19 STORE_FAST 2 (x3)
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)
Як бачите, множення та піднесення до степеня взагалі не забирають часу, оскільки вони закінчуються, коли компілюється код. Ділення триває довше, оскільки це відбувається під час виконання. Квадратний корінь - це не тільки найбільш обчислювальна з розрахунку операція з чотирьох, вона також спричиняє різні накладні витрати, яких немає у інших (пошук атрибутів, виклик функції тощо).
Якщо усунути ефект постійного згортання, множення та ділення мало відокремлювати:
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)
насправді трохи швидше, ніж x ** 0.5
, мабуть, тому, що це особливий випадок останнього, і тому його можна зробити ефективніше, незважаючи на загальні витрати:
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
редагувати 16.11.2011: Постійне згортання виразів здійснюється за допомогою оптичного оптика Python. Вихідний код ( peephole.c
) містить наступний коментар, який пояснює, чому константне ділення не складається:
case BINARY_DIVIDE:
return 0;
-Qnew
Прапор дозволяє «справжнє поділ» , певне в PEP 238 .