Çarpma mı bölme mi kullanmalıyım?

İşte aptalca eğlenceli bir soru:

Diyelim ki bir değişkenin değerinin yarısına ihtiyacımız olan basit bir işlem yapmalıyız. Bunu yapmanın tipik olarak iki yolu vardır :

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

Dil ile sağlanan standart operatörleri kullandığımızı varsayarsak, hangisinin performansı daha iyidir?

Çarpmanın genellikle daha iyi olduğunu tahmin ediyorum, bu yüzden kodlarken buna bağlı kalmaya çalışıyorum, ancak bunu onaylamak istiyorum.

Kişisel olarak Python 2.4-2.5'in cevabıyla ilgileniyor olsam da, diğer diller için de bir cevap göndermekten çekinmeyin! Ve isterseniz, diğer daha güzel yolları da (bitsel kaydırma operatörlerini kullanmak gibi) yayınlamaktan çekinmeyin.

Python:

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

çarpma% 33 daha hızlı

Lua:

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

=> gerçek bir fark yok

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

=> sadece% 5 daha hızlı

sonuçlar: Python'da çarpmak bölmekten daha hızlıdır, ancak daha gelişmiş VM'ler veya JIT'ler kullanarak CPU'ya yaklaştıkça avantaj ortadan kalkar. Gelecekteki bir Python sanal makinesinin onu alakasız hale getirmesi oldukça olasıdır

Daima en net olanı kullanın. Yaptığınız başka herhangi bir şey, derleyiciyi alt etmeye çalışmaktır. Derleyici tamamen zekiyse, sonucu optimize etmek için elinden gelenin en iyisini yapar, ancak hiçbir şey bir sonraki kişinin berbat bit değiştirme çözümünüz için sizden nefret etmemesini sağlayamaz (Bu arada biraz manipülasyonu seviyorum, eğlenceli. Ama eğlenceli! = Okunabilir )

Erken optimizasyon, tüm kötülüklerin köküdür. Optimizasyonun üç kuralını her zaman hatırlayın!

1. Optimize etmeyin.
2. Eğer bir uzmansanız, 1. kurala bakın

3. Bir uzmansanız ve ihtiyacı haklı çıkarabiliyorsanız, aşağıdaki prosedürü kullanın:

   • Optimize edilmemiş kodlayın
   • "Yeterince hızlı" ne kadar hızlı olduğunu belirleyin - Hangi kullanıcı gereksiniminin / hikayesinin bu ölçüyü gerektirdiğini not edin.
   • Bir hız testi yazın
   • Mevcut kodu test edin - Yeterince hızlıysa, bitirdiniz.
   • Optimize edilmiş olarak yeniden kodlayın
   • Optimize edilmiş kodu test edin. Metriği karşılamıyorsa, onu atın ve orijinali saklayın.
   • Testi karşılıyorsa, orijinal kodu yorum olarak saklayın

Ayrıca, gerekli olmadıklarında iç döngüleri kaldırmak veya bir ekleme sıralaması için bir dizi üzerinden bağlantılı bir liste seçmek gibi şeyler yapmak optimizasyon değil, sadece programlama.

Bence bu o kadar titizleşiyor ki, kodu daha okunaklı kılan her şeyi yapsanız daha iyi olur. İşlemleri milyonlarca olmasa da binlerce kez gerçekleştirmezseniz, birinin farkı anlayacağından şüpheliyim.

Eğer gerçekten seçim yapmanız gerekiyorsa, gidilecek tek yol kıyaslama yapmaktır. Hangi işlevlerin size sorun verdiğini bulun, ardından sorunların işlevin neresinde ortaya çıktığını bulun ve bu bölümleri düzeltin. Bununla birlikte, tek bir matematiksel işlemin (hatta birçok kez tekrarlanan) herhangi bir darboğazın nedeni olacağından hala şüpheliyim.

Çarpma daha hızlıdır, bölme daha doğrudur. Numaranız 2'nin kuvveti değilse biraz hassasiyet kaybedersiniz:

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

Derleyicinin tersine çevrilmiş sabiti mükemmel hassasiyete bulmasına izin verseniz bile, cevap yine de farklı olabilir.

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

Hız sorununun yalnızca C / C ++ veya JIT dillerinde ve hatta işlemin darboğazda bir döngüde olması durumunda önemli olması muhtemeldir.

Kodunuzu optimize etmek istiyor ancak yine de net olmak istiyorsanız, şunu deneyin:

y = x * (1.0 / 2.0);

Derleyici, bölmeyi derleme zamanında yapabilmelidir, böylece çalışma zamanında bir çarpma elde edersiniz. Kesinliğin y = x / 2.0durumdakiyle aynı olmasını beklerdim .

Bunun önemli olduğu durumlarda LOT, kayan nokta aritmetiğini hesaplamak için kayan nokta öykünmesinin gerekli olduğu gömülü işlemcilerdedir.

"Diğer diller" seçeneği için bir şeyler ekleyeceğim.
C: Bu gerçekten fark yaratmayan akademik bir alıştırma olduğu için , farklı bir şeye katkıda bulunacağımı düşündüm.

Optimizasyon yapmadan montaj için derledim ve sonuca baktım.
Kod:

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;

}

ile derlendi gcc tdiv.c -O1 -o tdiv.s -S

2'ye bölme:

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

ve 0,5 ile çarpma:

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)

Ancak, bunları ints olarak değiştirdiğimde double(ki bu muhtemelen python'un yapacağı şeydir), şunu elde ettim:

bölünme:

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

çarpma işlemi:

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

Bu kodun hiçbirini karşılaştırmadım, ancak sadece kodu inceleyerek, 2'ye bölmenin 2 ile çarpmadan daha kısa olduğunu görebilirsiniz. Çiftler kullanıldığında, çarpma daha kısadır çünkü derleyici işlemcinin kayan noktalı işlem kodlarını kullanır. muhtemelen aynı işlem için kullanmamaktan daha hızlı koşar (ama aslında bilmiyorum). Sonuç olarak, bu cevap, çoklu işlemin performansının 0,5'e karşı 2'ye bölünmesinin, dilin uygulanmasına ve üzerinde çalıştığı platforma bağlı olduğunu göstermiştir. Sonuçta, fark önemsizdir ve okunabilirlik dışında, neredeyse asla endişelenmemeniz gereken bir şeydir.

Bir yan not olarak, programımın main()geri döndüğünü görebilirsiniz a + b. Uçucu anahtar kelimeyi elimden aldığımda, derlemenin neye benzediğini asla tahmin edemezsiniz (program kurulumu hariç):

## 5/2

## 5*0.5
## done

movl    $5, %eax
leave
ret

hem bölmeyi, hem çarpmayı hem de toplamayı tek bir talimatta yaptı! Optimize edici herhangi bir saygıdeğer ise, bunun için endişelenmenize gerek yok.

Aşırı uzun cevap için özür dilerim.

İlk olarak, C veya ASSEMBLY'de çalışmadığınız sürece, muhtemelen hafızanın durduğu ve genel arama genel giderlerinin, çarpma ve ilgisizlik noktasına kadar bölme arasındaki farkı kesinlikle gölgede bırakacağı daha yüksek seviyeli bir dildesiniz. Öyleyse, bu durumda neyin daha iyi okunacağını seçin.

Çok yüksek bir seviyeden konuşuyorsanız, onu kullanma olasılığınız olan herhangi bir şey için ölçülebilir şekilde daha yavaş olmayacaktır. Diğer cevaplarda göreceksiniz, insanların sadece ikisi arasındaki milisaniyenin altındaki bir farkı ölçmek için bir milyon çarpma / bölme yapması gerekiyor.

Düşük seviye optimizasyon açısından hala merak ediyorsanız:

Bölünme, çarpmadan çok daha uzun bir ardışık düzene sahip olma eğilimindedir. Bu, sonucu almanın daha uzun sürdüğü anlamına gelir, ancak işlemciyi bağımlı olmayan görevlerle meşgul tutabilirseniz, o zaman size bir çarpmadan daha pahalıya mal olmaz.

Boru hattı farkının ne kadar süreceği tamamen donanıma bağlıdır. Kullandığım son donanım FPU çarpımı için 9 döngü ve FPU bölme için 50 döngü gibi bir şeydi. Kulağa çok geliyor, ama sonra bir hafıza kaybı için 1000 döngü kaybedersiniz, bu da işleri perspektif haline getirebilir.

Bir benzetme, bir TV şovunu izlerken mikrodalgaya bir turta koymaktır. Sizi TV programından ayırdığı toplam süre, onu mikrodalgaya koyup mikrodalgadan çıkarmanın ne kadar sürdüğüdür. Geri kalan zamanınızda hala TV programını izlediniz. Yani pastanın pişirilmesi 1 dakika yerine 10 dakika sürdüyse, aslında artık televizyon izleme sürenizi tüketmiyordu.

Pratikte, Multiply ve Divide arasındaki farkı önemseme düzeyine ulaşacaksanız, ardışık düzenleri, önbelleği, dal duraklarını, sıra dışı tahmini ve boru hattı bağımlılıklarını anlamanız gerekir. Bu soruyla nereye gitmeyi düşündüğünüz gibi gelmiyorsa, doğru cevap ikisi arasındaki farkı görmezden gelmektir.

Yıllar önce, bölünmelerden kaçınmak ve her zaman çoğalmaları kullanmak kesinlikle kritikti, ancak o zamanlar hafıza vuruşları daha az alakalıydı ve bölünmeler çok daha kötüydü. Bu günlerde okunabilirliği daha yüksek değerlendiriyorum, ancak okunabilirlik farkı yoksa, çarpımları tercih etmenin iyi bir alışkanlık olduğunu düşünüyorum.

Hangisi daha açık bir şekilde niyetinizi belirtirse yazın.

Programınız çalıştıktan sonra neyin yavaş olduğunu bulun ve bunu hızlandırın.

Bunu başka şekilde yapma.

Neye ihtiyacın varsa onu yap. Önce okuyucunuzu düşünün, bir performans sorununuz olduğundan emin olana kadar performans konusunda endişelenmeyin.

Bırakın derleyici performansı sizin için yapsın.

Tamsayılarla veya kayan nokta olmayan türlerle çalışıyorsanız, bit kaydırma operatörlerinizi unutmayın: << >>

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

Aslında genel bir kural olarak çarpmanın bölmeden daha hızlı olmasının iyi bir nedeni var. Donanımdaki kayan nokta bölümü, ya kaydırma ve koşullu çıkarma algoritmalarıyla (ikili sayılarla "uzun bölme") veya - bugünlerde daha büyük olasılıkla - Goldschmidt'in algoritması gibi yinelemelerle yapılır . Kaydırma ve çıkarma, hassasiyet biti başına en az bir döngüye ihtiyaç duyar (yinelemelerin, çarpmanın kaydır ve eklenmesi gibi paralelleştirilmesi neredeyse imkansızdır) ve yinelemeli algoritmalar en az bir çarpma yapar başına. Her iki durumda da, bölümün daha fazla döngü alması muhtemeldir. Elbette bu, derleyicilerdeki, veri hareketindeki veya hassasiyetteki tuhaflıkları hesaba katmaz. Genel olarak, bir programın zamana duyarlı bir bölümünde bir iç döngü kodluyorsanız,0.5 * xya da 1.0/2.0 * xdaha ziyade x / 2.0makul bir şeydir. "En açık olanı kodlayın" ın bilgiçliği kesinlikle doğrudur, ancak bunların üçü de okunabilirlik açısından o kadar yakındır ki, bu durumda bilgiçlik sadece bilgiçlikçidir.

Çarpmanın daha verimli olduğunu hep öğrendim.

Çarpma genellikle daha hızlıdır - kesinlikle asla daha yavaş değildir. Ancak, hız açısından kritik değilse, hangisi en açıksa onu yazın.

Kayan nokta bölmesi (genellikle) özellikle yavaştır, bu nedenle kayan nokta çarpımı da nispeten yavaş olsa da, muhtemelen kayan nokta bölmesinden daha hızlıdır.

Ancak profil oluşturma, bölmenin çarpmaya karşı biraz darboğaz olduğunu göstermedikçe, "gerçekten önemli değil" yanıtını vermeye daha meyilliyim. Yine de, çarpma ve bölme seçiminin uygulamanızda büyük bir performans etkisi olmayacağını tahmin ediyorum.

Montajda veya belki C'de programlama yaparken bu daha çok bir soru haline geliyor. Çoğu modern dilde bunun gibi optimizasyonun benim için yapıldığını düşünüyorum.

"Çarpmanın genellikle daha iyi olduğunu tahmin etmek daha iyidir, bu yüzden kodlarken buna bağlı kalmaya çalışırım" konusunda dikkatli olun.

Bu özel soru bağlamında, burada daha iyisi, "daha hızlı" anlamına gelir. Bu pek kullanışlı değil.

Hız hakkında düşünmek ciddi bir hata olabilir. Hesaplamanın özgül cebirsel biçiminde büyük hata çıkarımları vardır.

Hata analizi ile Kayan Nokta aritmetiği bölümüne bakınız . Kayan Nokta Aritmetiği ve Hata Analizinde Temel Konulara bakınız .

Bazı kayan nokta değerleri kesin olsa da, çoğu kayan nokta değeri yaklaşıktır; bunlar ideal bir değer artı bazı hatalardır. Her işlem ideal değer ve hata değeri için geçerlidir.

En büyük sorunlar, neredeyse eşit iki sayıyı manipüle etmeye çalışmaktan kaynaklanıyor. En sağdaki bitler (hata bitleri) sonuçlara hakim olur.

>>> 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

Bu örnekte, değerler küçüldükçe, neredeyse eşit sayılar arasındaki farkın, doğru cevabın sıfır olduğu sıfır olmayan sonuçlar oluşturduğunu görebilirsiniz.

C / C ++ 'da çarpmanın daha verimli olduğunu bir yerde okudum; Tercüme edilmiş diller hakkında hiçbir fikrim yok - diğer tüm ek yükler nedeniyle fark muhtemelen ihmal edilebilir.

Daha sürdürülebilir / okunabilir olanla ilgili bir sorun haline gelmedikçe - insanların bana bunu söylemesinden nefret ediyorum ama bu çok doğru.

Genel olarak çarpmayı öneririm, çünkü döngüleri böleninizin 0 olmadığından emin olmak için harcamanıza gerek yoktur. Böleniniz bir sabitse, elbette bu geçerli değildir.

Samsung GT-S5830 üzerinde profilli 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;
    }
}

Sonuçlar?

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

Bölme, çarpmadan yaklaşık% 20 daha hızlıdır (!)

24 numaralı (çarpma daha hızlı) ve 30 numaralı gönderilerde olduğu gibi - ancak bazen ikisi de anlaşılması kadar kolaydır:

1*1e-6F;

1/1e6F;

~ İkisini de okumak kadar kolay buluyorum ve milyarlarca kez tekrar etmem gerekiyor. Bu yüzden çarpmanın genellikle daha hızlı olduğunu bilmek faydalıdır.

Bir fark vardır, ancak derleyiciye bağlıdır. İlk olarak vs2003 (c ++) 'da çift tipler (64 bit kayan nokta) için önemli bir fark görmedim. Bununla birlikte, testleri tekrar vs2010'da çalıştırdığımda, çarpımlar için 4 faktöre kadar daha hızlı büyük bir fark tespit ettim. Bunu takip ederek, vs2003 ve vs2010'un farklı fpu kodu ürettiği anlaşılıyor.

Pentium 4, 2.8 GHz, 2003'e karşı:

• Çarpma: 8.09
• Bölüm: 7.97

Xeon W3530, vs2003'te:

• Çarpma: 4.68
• Bölüm: 4.64

Xeon W3530, vs2010'da:

• Çarpma: 5.33
• Bölüm: 21.05

Öyle görünüyor ki, vs2003'te döngüdeki bir bölme (bölen birden çok kez kullanıldı) ters ile çarpmaya çevrildi. Vs2010'da bu optimizasyon artık uygulanmıyor (sanırım iki yöntem arasında biraz farklı sonuç olduğu için). Ayrıca, payınız 0.0 olduğunda cpu'nun bölmeleri daha hızlı gerçekleştirdiğini unutmayın. Çipte bulunan hassas algoritmayı bilmiyorum, ama belki sayıya bağlı.

Edit 18-03-2013: vs2010 için gözlem

İşte aptalca eğlenceli bir cevap:

x / 2.0 , x * 0.5'e eşdeğer değildir

Diyelim ki bu yöntemi 22 Ekim 2008'de yazdınız.

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

Şimdi, 10 yıl sonra bu kod parçasını optimize edebileceğinizi öğreniyorsunuz. Yönteme, uygulamanız boyunca yüzlerce formülde başvurulur. Yani onu değiştirirsiniz ve% 5'lik dikkate değer bir performans artışı yaşarsınız.

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

Kodu değiştirmek doğru bir karar mıydı? Matematikte iki ifade gerçekten eşdeğerdir. Bilgisayar biliminde bu her zaman doğru değildir. Daha fazla ayrıntı için lütfen Doğruluk sorunlarının etkisini en aza indirme bölümünü okuyun . Hesaplanan değerleriniz - bir noktada - diğer değerlerle karşılaştırılırsa, uç durumların sonucunu değiştirirsiniz. Örneğin:

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

Alt satırda; ikisinden birine razı olduktan sonra, ona sadık kalın!

Bir toplama / çıkarma işleminin maliyetinin 1 olduğunu varsayarsak, maliyeti 5'i çarpın ve maliyetleri yaklaşık 20'ye bölün.

Böylesine uzun ve ilginç bir tartışmadan sonra, benim şu konuyu ele alıyorum: Bu sorunun nihai cevabı yok. Bazı insanların da belirttiği gibi, hem donanıma (cf piotrk ve gast128 ) hem de derleyiciye (cf @Javier testleri) bağlıdır. Hız kritik değilse, uygulamanızın gerçek zamanlı büyük miktarda veriyi işlemesi gerekmiyorsa, bir bölme kullanarak netliği tercih edebilirsiniz, oysa işlem hızı veya işlemci yükü bir sorunsa, çarpma en güvenli olabilir. Son olarak, uygulamanızın hangi platformda kullanılacağını tam olarak bilmiyorsanız, kıyaslama anlamsızdır. Ve kod netliği için, tek bir yorum iş görür!

Teknik olarak bölme diye bir şey yoktur, sadece ters elemanlarla çarpma vardır. Örneğin, asla 2'ye bölmezsiniz, aslında 0,5 ile çarparsınız.

'Bölümü' - bu bir saniye var olduğu edelim kendimize çocuk - çünkü 'böl' zor hep çarpma olduğu xkadar ydeğeri hesaplamak için bir ilk ihtiyaçlar y^{-1}öyle ki y*y^{-1} = 1daha sonra çarpma yapmak x*y^{-1}. Zaten biliyorsanız, y^{-1}o zaman hesaplamamak ybir optimizasyon olmalıdır.