곱셈이나 나눗셈을 사용해야합니까?

다음은 어리석은 재미있는 질문입니다.

변수 값의 절반이 필요한 간단한 작업을 수행해야한다고 가정 해 보겠습니다. 있다 일반적으로 이 일을 두 가지 방법 :

y = x / 2.0;
// or...
y = x * 0.5;

언어와 함께 제공되는 표준 연산자를 사용한다고 가정하면 어느 것이 더 나은 성능을 제공합니까?

나는 곱셈이 일반적으로 더 낫다고 생각하기 때문에 코딩 할 때 그것을 고수하려고 노력하지만 이것을 확인하고 싶습니다.

개인적으로 Python 2.4-2.5 에 대한 답변에 관심이 있지만 다른 언어에 대한 답변도 자유롭게 게시 할 수 있습니다! 그리고 원한다면 다른 멋진 방법 (비트 시프트 연산자 사용과 같은)도 자유롭게 게시 할 수 있습니다.

파이썬 :

time python -c 'for i in xrange(int(1e8)): t=12341234234.234 / 2.0'
real    0m26.676s
user    0m25.154s
sys     0m0.076s

time python -c 'for i in xrange(int(1e8)): t=12341234234.234 * 0.5'
real    0m17.932s
user    0m16.481s
sys     0m0.048s

곱셈은 ​​33 % 더 빠릅니다

루아 :

time lua -e 'for i=1,1e8 do t=12341234234.234 / 2.0 end'
real    0m7.956s
user    0m7.332s
sys     0m0.032s

time lua -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end'
real    0m7.997s
user    0m7.516s
sys     0m0.036s

=> 실제 차이 없음

LuaJIT :

time luajit -O -e 'for i=1,1e8 do t=12341234234.234 / 2.0 end'
real    0m1.921s
user    0m1.668s
sys     0m0.004s

time luajit -O -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end'
real    0m1.843s
user    0m1.676s
sys     0m0.000s

=> 5 % 만 더 빠름

결론 : Python에서는 나누는 것보다 곱하는 것이 더 빠르지 만 고급 VM 또는 JIT를 사용하여 CPU에 가까워지면 이점이 사라집니다. 미래의 Python VM이이를 무의미하게 만들 가능성이 높습니다.

항상 가장 명확한 것을 사용하십시오. 당신이하는 다른 일은 컴파일러를 능가하려는 것입니다. 컴파일러가 지능적이라면 결과를 최적화하기 위해 최선을 다할 것입니다.하지만 그 어떤 것도 당신의 엉뚱한 비트 시프 팅 솔루션에 대해 다음 사람이 당신을 싫어하지 않게 만들 수는 없습니다. )

조기 최적화는 모든 악의 근원입니다. 항상 최적화의 세 가지 규칙을 기억하십시오!

1. 최적화하지 마십시오.
2. 전문가 인 경우 규칙 # 1을 참조하십시오.

3. 전문가이고 필요를 정당화 할 수있는 경우 다음 절차를 사용하십시오.

   • 최적화되지 않은 코딩
   • "충분히 빠른"속도 결정-어떤 사용자 요구 사항 / 스토리에 해당 메트릭이 필요한지 확인합니다.
   • 속도 테스트 작성
   • 기존 코드 테스트-충분히 빠르면 완료된 것입니다.
   • 최적화 된 레코딩
   • 최적화 된 코드를 테스트합니다. 측정 기준에 맞지 않으면 버리고 원본을 보관하십시오.
   • 테스트를 충족하면 원본 코드를 주석으로 유지하십시오.

또한 필요하지 않을 때 내부 루프를 제거하거나 삽입 정렬을 위해 배열에 연결된 목록을 선택하는 것과 같은 작업을 수행하는 것은 최적화가 아니라 프로그래밍입니다.

나는 이것이 너무 간결 해져서 코드를 더 읽기 쉽게 만드는 것이 더 나을 것이라고 생각합니다. 수백만 번은 아니더라도 수천 번의 작업을 수행하지 않는 한 누구도 그 차이를 눈치 채지 못할 것입니다.

정말로 선택을해야한다면 벤치마킹이 유일한 방법입니다. 어떤 기능이 문제를 일으키는 지 찾은 다음 기능에서 문제가 발생하는 위치를 찾아 해당 섹션을 수정하십시오. 그러나 나는 여전히 하나의 수학적 연산 (한 번이라도 여러 번 반복)이 병목 현상의 원인이 될 것이라고 의심합니다.

곱셈이 더 빠르고 나눗셈이 더 정확합니다. 숫자가 2의 거듭 제곱이 아니면 정밀도를 잃게됩니다.

y = x / 3.0;
y = x * 0.333333;  // how many 3's should there be, and how will the compiler round?

컴파일러가 반전 된 상수를 완벽한 정밀도로 알아 내도록하더라도 대답은 여전히 ​​다를 수 있습니다.

x = 100.0;
x / 3.0 == x * (1.0/3.0)  // is false in the test I just performed

속도 문제는 C / C ++ 또는 JIT 언어에서만 문제가 될 수 있으며, 작업이 병목 상태의 루프에있는 경우에만 중요합니다.

코드를 최적화하고 싶지만 여전히 명확하다면 다음을 시도하십시오.

y = x * (1.0 / 2.0);

컴파일러는 컴파일 타임에 분할을 수행 할 수 있어야하므로 런타임에 곱셈을 얻을 수 있습니다. 정밀도는 y = x / 2.0케이스 와 동일 할 것으로 예상합니다 .

이것이 중요한 경우 부동 소수점 산술을 계산하기 위해 부동 소수점 에뮬레이션이 필요한 임베디드 프로세서에 LOT가 있습니다.

"다른 언어"옵션에 대한 내용을 추가합니다.
C : 이건 정말 큰 차이가없는 학문적 운동이기 때문에 뭔가 다른 것에 기여할 것이라고 생각했습니다.

최적화없이 어셈블리로 컴파일하고 결과를 확인했습니다.
코드:

int main() {

    volatile int a;
    volatile int b;

    asm("## 5/2\n");
    a = 5;
    a = a / 2;

    asm("## 5*0.5");
    b = 5;
    b = b * 0.5;

    asm("## done");

    return a + b;

}

컴파일 gcc tdiv.c -O1 -o tdiv.s -S

2로 나누기 :

movl    $5, -4(%ebp)
movl    -4(%ebp), %eax
movl    %eax, %edx
shrl    $31, %edx
addl    %edx, %eax
sarl    %eax
movl    %eax, -4(%ebp)

0.5 곱하기 :

movl    $5, -8(%ebp)
movl    -8(%ebp), %eax
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fmuls   LC0
fnstcw  -10(%ebp)
movzwl  -10(%ebp), %eax
orw $3072, %ax
movw    %ax, -12(%ebp)
fldcw   -12(%ebp)
fistpl  -16(%ebp)
fldcw   -10(%ebp)
movl    -16(%ebp), %eax
movl    %eax, -8(%ebp)

그러나 그 ints를 doubles로 변경했을 때 (파이썬이 아마도 할 것입니다), 나는 이것을 얻었습니다.

분할:

flds    LC0
fstl    -8(%ebp)
fldl    -8(%ebp)
flds    LC1
fmul    %st, %st(1)
fxch    %st(1)
fstpl   -8(%ebp)
fxch    %st(1)

곱셈:

fstpl   -16(%ebp)
fldl    -16(%ebp)
fmulp   %st, %st(1)
fstpl   -16(%ebp)

이 코드를 벤치마킹하지는 않았지만 코드를 살펴보면 정수를 사용하는 것만으로도 2로 나누는 것이 2로 나누는 것보다 짧다는 것을 알 수 있습니다. double을 사용하면 컴파일러가 프로세서의 부동 소수점 연산 코드를 사용하기 때문에 곱셈이 더 짧습니다. 동일한 작업에 사용하지 않는 것보다 더 빨리 실행될 수 있습니다 (실제로는 모르겠습니다). 따라서 궁극적으로이 답변은 0.5 곱셈의 성능과 2로 나누기의 성능은 언어의 구현과 실행되는 플랫폼에 달려 있음을 보여줍니다. 궁극적으로 그 차이는 무시할 만하 며 가독성 측면을 제외하고는 거의 걱정할 필요가 없습니다.

참고로 내 프로그램 main()에서 a + b. volatile 키워드를 제거하면 어셈블리가 어떻게 생겼는지 추측하지 못할 것입니다 (프로그램 설정 제외).

## 5/2

## 5*0.5
## done

movl    $5, %eax
leave
ret

하나의 명령어로 나누기, 곱하기, 더하기를 모두 수행했습니다! 옵티마이 저가 어떤 종류의 존경받을 만하다면 이것에 대해 걱정할 필요가 없습니다.

답변이 너무 길어서 죄송합니다.

첫째, C 또는 ASSEMBLY로 작업하지 않는 한, 아마도 메모리 지연과 일반적인 호출 오버 헤드가 곱셈과 나누기의 차이를 무관 한 지점까지 절대적으로 작게 만드는 더 높은 수준의 언어에있을 것입니다. 따라서이 경우 더 잘 읽는 것을 선택하십시오.

매우 높은 수준에서 이야기하는 경우 사용할 가능성이있는 모든 것에 대해 눈에 띄게 느려지지 않습니다. 다른 답변에서 볼 수 있듯이 사람들은 둘 사이의 밀리 초 미만의 차이를 측정하기 위해 백만 번의 곱셈 / 나눗셈을 수행해야합니다.

여전히 궁금하다면 낮은 수준의 최적화 관점에서 :

Divide는 곱하기보다 파이프 라인이 훨씬 더 긴 경향이 있습니다. 즉, 결과를 얻는 데 시간이 더 오래 걸리지 만 프로세서를 비 종속 작업으로 바쁘게 유지할 수 있다면 곱하기보다 더 많은 비용이 들지 않습니다.

파이프 라인 차이는 완전히 하드웨어에 따라 다릅니다. 마지막으로 사용한 하드웨어는 FPU 곱셈에 9 사이클, FPU 분할에 50 사이클 정도였습니다. 많이 들리지만 기억을 놓치면 1000 사이클을 잃게되므로 상황을 원근감있게 표현할 수 있습니다.

비유는 TV 쇼를 보는 동안 전자 레인지에 파이를 넣는 것입니다. TV 쇼를 보지 않는 데 걸린 총 시간은 전자 레인지에 넣고 전자 레인지에서 꺼내는 데 걸린 시간입니다. 나머지 시간은 여전히 ​​TV 쇼를 봤습니다. 따라서 파이가 요리하는 데 1 분이 아닌 10 분이 걸린다면 실제로 TV 시청 시간을 더 이상 사용하지 않은 것입니다.

실제로 Multiply와 Divide의 차이를 신경 쓰는 수준에 도달하려면 파이프 라인, 캐시, 분기 지연, 비 순차 예측 및 파이프 라인 종속성을 이해해야합니다. 이것이 당신 이이 질문으로 가고자했던 곳과 같지 않다면 정답은 둘의 차이를 무시하는 것입니다.

수년 전에는 분할을 피하고 항상 곱셈을 사용하는 것이 절대적으로 중요했지만 당시에는 메모리 히트가 덜 적절했고 분할이 훨씬 더 나빴습니다. 요즘 나는 가독성을 더 높게 평가하지만 가독성 차이가 없다면 곱셈을 선택하는 것이 좋은 습관이라고 생각합니다.

당신의 의도를 더 명확하게 나타내는 것을 작성하십시오.

프로그램이 작동 한 후 무엇이 느린 지 파악하고 더 빠르게 만드십시오.

다른 방식으로하지 마십시오.

필요한 것은 무엇이든하십시오. 먼저 독자를 생각하고 성능 문제가 있음을 확신 할 때까지 성능에 대해 걱정하지 마십시오.

컴파일러가 성능을 수행하도록하십시오.

정수 또는 비 부동 소수점 유형으로 작업하는 경우 비트 시프 팅 연산자를 잊지 마십시오. << >>

    int y = 10;
    y = y >> 1;
    Console.WriteLine("value halved: " + y);
    y = y << 1;
    Console.WriteLine("now value doubled: " + y);

사실 일반적으로 곱셈이 나눗셈보다 빠르다는 좋은 이유가 있습니다. 하드웨어의 부동 소수점 나누기는 시프트 및 조건부 빼기 알고리즘 (이진수로 "긴 나누기") 또는-요즘에는 Goldschmidt의 알고리즘 과 같은 반복으로 수행 됩니다. 시프트 및 빼기는 정밀도 비트 당 적어도 하나의 사이클이 필요하며 (반복은 시프트 및 곱셈의 더하기와 같이 병렬화가 거의 불가능합니다) 반복 알고리즘은 반복 당 적어도 한 번의 곱셈을 수행합니다.. 두 경우 모두 부서에 더 많은주기가 걸릴 가능성이 높습니다. 물론 이것은 컴파일러, 데이터 이동 또는 정밀도의 단점을 설명하지 않습니다. 전반적으로, 그러나, 당신은 프로그램, 글을 쓰는 시간에 민감한 부분에 내부 루프를 코딩하는 경우 0.5 * x또는 1.0/2.0 * x이 아닌 것은 x / 2.0할 수있는 합리적인 일이다. "가장 명확한 코드를 작성하라"라는 pedantry는 절대적으로 사실이지만,이 세 가지 모두 가독성이 너무 가깝기 때문에이 경우 pedantry는 현학적 인 것입니다.

저는 곱셈이 더 효율적이라는 것을 항상 배웠습니다.

곱셈은 ​​일반적으로 더 빠르며 결코 느리지 않습니다. 그러나 속도가 중요하지 않은 경우 가장 명확한 것을 작성하십시오.

부동 소수점 나누기는 (일반적으로) 특히 느리므로 부동 소수점 곱셈도 비교적 느리지 만 부동 소수점 나누기보다 빠를 것입니다.

그러나 프로파일 링에서 분할이 약간의 병목 현상과 곱셈이라는 것을 보여주지 않는 한, 저는 "그건 중요하지 않습니다"라고 대답하는 경향이 있습니다. 하지만 곱셈과 나눗셈의 선택이 응용 프로그램의 성능에 큰 영향을 미치지는 않을 것이라고 생각합니다.

이것은 어셈블리 나 아마도 C로 프로그래밍 할 때 더 많은 질문이됩니다. 저는 대부분의 현대 언어에서 이와 같은 최적화가 저를 위해 수행되고 있다고 생각합니다.

"곱하기가 일반적으로 더 낫다고 생각하기 때문에 코딩 할 때 그것을 고수하려고합니다."

이 특정 질문의 맥락에서 더 나은 것은 "더 빠름"을 의미합니다. 별로 유용하지 않습니다.

속도에 대해 생각하는 것은 심각한 실수가 될 수 있습니다. 계산의 특정 대수 형식에는 심각한 오류 의미가 있습니다.

오류 분석을 사용한 부동 소수점 산술을 참조하십시오 . 부동 소수점 산술 및 오류 분석의 기본 문제를 참조하십시오 .

일부 부동 소수점 값은 정확하지만 대부분의 부동 소수점 값은 근사치입니다. 그들은 이상적인 가치와 약간의 오류입니다. 모든 작업은 이상적인 값과 오류 값에 적용됩니다.

가장 큰 문제는 거의 동일한 두 개의 숫자를 조작하려고 할 때 발생합니다. 가장 오른쪽 비트 (오류 비트)가 결과를 지배하게됩니다.

>>> for i in range(7):
...     a=1/(10.0**i)
...     b=(1/10.0)**i
...     print i, a, b, a-b
... 
0 1.0 1.0 0.0
1 0.1 0.1 0.0
2 0.01 0.01 -1.73472347598e-18
3 0.001 0.001 -2.16840434497e-19
4 0.0001 0.0001 -1.35525271561e-20
5 1e-05 1e-05 -1.69406589451e-21
6 1e-06 1e-06 -4.23516473627e-22

이 예에서는 값이 작아 질수록 거의 같은 수의 차이가 정답이 0 인 0이 아닌 결과를 생성한다는 것을 알 수 있습니다.

나는 어딘가에서 C / C ++에서 곱셈이 더 효율적이라는 것을 읽었습니다. 통역 언어에 대한 아이디어가 없습니다. 다른 모든 오버 헤드로 인해 그 차이는 무시할 수 있습니다.

더 유지하기 쉽고 가독성이 좋은 것에 문제가되지 않는 한-사람들이 나에게 이것을 말하는 것이 싫지만 너무 사실입니다.

제수가 0이 아닌지 확인하기 위해주기를 소비 할 필요가 없기 때문에 일반적으로 곱셈을 제안합니다. 물론 제수가 상수 인 경우에는 적용되지 않습니다.

Samsung GT-S5830에 프로파일 링 된 Java Android

public void Mutiplication()
{
    float a = 1.0f;

    for(int i=0; i<1000000; i++)
    {
        a *= 0.5f;
    }
}
public void Division()
{
    float a = 1.0f;

    for(int i=0; i<1000000; i++)
    {
        a /= 2.0f;
    }
}

결과?

Multiplications():   time/call: 1524.375 ms
Division():          time/call: 1220.003 ms

나누기는 곱셈 (!)보다 약 20 % 빠릅니다.

게시물 # 24 (곱하기가 더 빠름) 및 # 30과 마찬가지로-때로는 둘 다 이해하기 쉽습니다.

1*1e-6F;

1/1e6F;

~ 두 가지 모두 읽기 쉽고 수십억 번 반복해야합니다. 따라서 곱셈이 일반적으로 더 빠르다는 것을 아는 것이 유용합니다.

차이가 있지만 컴파일러에 따라 다릅니다. 처음에는 vs2003 (C ++)에서 이중 유형 (64 비트 부동 소수점)에 대해 큰 차이가 없었습니다. 그러나 vs2010에서 테스트를 다시 실행하면 곱셈에 대해 최대 4 배까지 빠른 차이를 발견했습니다. 이것을 추적하면 vs2003과 vs2010이 다른 fpu 코드를 생성하는 것으로 보입니다.

Pentium 4, 2.8GHz, vs2003 :

• 곱셈 : 8.09
• 나눗셈 : 7.97

Xeon W3530, vs2003 :

• 곱셈 : 4.68
• 나눗셈 : 4.64

Xeon W3530, vs2010 :

• 곱셈 : 5.33
• 나눗셈 : 21.05

vs2003에서 루프의 나눗셈이 (따라서 제수가 여러 번 사용되었으므로) 역으로 곱셈으로 변환 된 것 같습니다. vs2010에서는이 최적화가 더 이상 적용되지 않습니다 (두 방법간에 결과가 약간 다르기 때문에 가정합니다). 또한 cpu는 분자가 0.0이 되 자마자 나눗셈을 더 빠르게 수행합니다. 칩에 고정 된 정확한 알고리즘은 모르지만 숫자에 따라 다를 수 있습니다.

18-03-2013 편집 : vs2010에 대한 관찰

어리석은 재미있는 대답이 있습니다.

x / 2.0 은 x * 0.5 와 동일 하지 않습니다.

이 방법을 2008 년 10 월 22 일에 작성했다고 가정 해 보겠습니다.

double half(double x) => x / 2.0;

이제 10 년 후이 코드를 최적화 할 수 있다는 것을 알게됩니다. 이 방법은 응용 프로그램 전체에서 수백 개의 공식에서 참조됩니다. 그래서 당신은 그것을 바꾸고 놀라운 5 % 성능 향상을 경험합니다.

double half(double x) => x * 0.5;

코드를 변경 한 것이 올바른 결정 이었습니까? 수학에서 두 표현은 실제로 동일합니다. 컴퓨터 과학에서 항상 그런 것은 아닙니다. 자세한 내용 은 정확도 문제의 영향 최소화 를 참조하십시오. 계산 된 값이 다른 값과 비교되는 경우-엣지 케이스의 결과가 변경됩니다. 예 :

double quantize(double x)
{
    if (half(x) > threshold))
        return 1;
    else
        return -1;
}

결론은 다음과 같습니다. 둘 중 하나에 만족하면 그것에 충실하십시오!

추가 / 하위 트랙 작업 비용이 1이라고 가정하면 비용 5를 곱하고 비용을 약 20으로 나눕니다.

이처럼 길고 흥미로운 논의 끝에 여기에 대한 나의 견해가 있습니다.이 질문에 대한 최종 답은 없습니다. 일부 사람들이 지적했듯이 하드웨어 ( piotrk 및 gast128 참조 )와 컴파일러 ( @Javier 의 테스트 참조)에 따라 다릅니다 . 속도가 중요하지 않은 경우 애플리케이션이 실시간으로 방대한 양의 데이터를 처리 할 필요가없는 경우 분할을 사용하여 명확성을 선택할 수 있지만 처리 속도 또는 프로세서로드가 문제가되는 경우 곱셈이 가장 안전 할 수 있습니다. 마지막으로 애플리케이션을 배포 할 플랫폼을 정확히 알지 못하는 한 벤치 마크는 의미가 없습니다. 그리고 코드의 명확성을 위해 하나의 주석으로 작업을 수행 할 수 있습니다!

기술적으로 나눗셈과 같은 것은 없으며 역 요소에 의한 곱셈 만 있습니다. 예를 들어 2로 나누지 않고 실제로 0.5를 곱합니다.

'부'- 그것은 잠시 존재 함을하자 아이 자신은 - 때문에 '분열'에 더 열심히 항상 곱셈이다 x하여 y값을 계산하기 위해 하나 개의 제 요구 y^{-1}등 그 y*y^{-1} = 1다음 곱셈을 x*y^{-1}. 이미 알고 있다면 y^{-1}계산하지 않는 것이 y최적화 여야합니다.