1 <10 karşılaştırması 1 <1000000'den daha mı ucuz?

Ben sadece ~ 1 milyar z-indexCSS için bir sayı olarak kullandım ve devam etmesi gereken karşılaştırmalar hakkında düşünüyordum. Çok büyük sayılarla çok küçük sayılar arasındaki karşılaştırmalarda ALU düzeyinde performans açısından bir fark var mı?

Örneğin, bu iki snippet'ten biri diğerinden daha pahalı mı olurdu?

snippet 1

for (int i = 0; i < 10000000; i++){
    if (i < 10000000000000) {
        //do nothing
    }
}

snippet 2

for (int i = 0; i < 10000000; i++){
    if (i < 1000) {
        //do nothing
    }
}

Çalıştığım her işlemci, işlenenlerden birini diğerinden çıkartarak, sonucu atarak ve işlemcinin bayraklarını (sıfır, negatif vb.) Tek başına bırakarak karşılaştırma yapar. Çıkarma tek bir işlem olarak yapıldığından, işlenenlerin içeriği önemli değil.

Soruyu kesin olarak yanıtlamanın en iyi yolu, kodunuzu montaj için derlemektir ve oluşturulan talimatlar için hedef işlemcinin belgelerine bakın. Mevcut Intel CPU'ları için bu Intel 64 ve IA-32 Architectures Yazılım Geliştirici El Kitabı olacaktır .

Açıklaması CMP( "karşılaştırma") talimat hacmi 2A, sayfa 3-126 veya PDF sayfa 618 olduğunu ve olarak çalışmasını anlatır:

temp ← SRC1 − SignExtend(SRC2);
ModifyStatusFlags; (* Modify status flags in the same manner as the SUB instruction*)

Bu, ikinci işlenenin gerekli olduğunda işaret uzatması, ilk işlenenden çıkarılması ve sonucun işlemcideki geçici bir alana yerleştirilmesi anlamına gelir. Ardından durum bayrakları SUB("çıkarma") komutunda (PDF'nin 1492. sayfasındaki) ayarlandığı gibi ayarlanır .

Orada hiçbir söz var CMPya SUBİşlenenlerin değerleri gecikme alakalı olması belgeler, kullandığınız herhangi bir değer güvenlidir.

Çok büyük sayılarla çok küçük sayılar arasındaki karşılaştırmalarda ALU düzeyinde performans açısından bir fark var mı?

Çok sayıda küçük numaradan gidiyor sayısal türünü değiştirir sürece, pek olası değil, bir gelen söylemek intbir etmek long. O zaman bile, fark önemli olmayabilir. Programlama diliniz sessizce kapakların altında isteğe bağlı hassas aritmetik geçiş yaparsa, bir fark görmeniz daha olasıdır .

Bununla birlikte, kendi derleyiciniz farkında olmadığınız bazı akıllı optimizasyonlar yapıyor olabilir. Öğrendiğiniz yol ölçmektir. Kodunuzda bir profil oluşturucu çalıştırın; hangi karşılaştırmaların en uzun sürdüğünü görün. Ya da sadece bir zamanlayıcı başlatmak ve durdurmak.

Pek çok işlemcinin, hemen belirtilen belirli işleçlerde, karşılaştırmalar dahil olmak üzere, aritmetik işlemleri gerçekleştirebilen "küçük" komutları vardır. Bu özel değerler dışındaki işlenenler ya daha geniş bir talimat formatı kullanmalı ya da bazı durumlarda "bellekten yük değeri" talimatını kullanmalıdır. ARM Cortex-M3 komut setinde, örneğin, bir değerin bir sabitle karşılaştırılabileceği en az beş yol vardır:

    cmp r0,#1      ; One-word instruction, limited to values 0-255

    cmp r0,#1000   ; Two-word instruction, limited to values 0-255 times a power of 2

    cmn r0,#1000   ; Equivalent to comparing value with -1000
                   ; Two-word instruction, limited to values 0-255 times a power of 2

    mov r1,#30000  ; Two words; can handle any value 0-65535
    cmp r0,r1      ; Could use cmn to compare to values -1 to -65535

    ldr r1,[constant1000000] ; One or two words, based upon how nearby the constant is
    cmp r0,r1
    ...

constant1000000:
    dd  1000000

İlk biçim en küçük olandır; ikinci ve üçüncü form, kodun alındığı hafızanın hızına bağlı olarak hızlı bir şekilde uygulanabilir veya çalışmayabilir. Dördüncü form neredeyse kesinlikle ilk üçten daha yavaştır ve beşinci form daha da yavaş olacaktır, ancak ikincisi herhangi bir 32-bit değerinde kullanılabilir.

Eski x86 işlemcilerinde, kısa form karşılaştırma talimatları, uzun formdakilerden daha hızlı çalıştırılır, ancak birçok yeni işlemci, ilk getirildiklerinde hem uzun hem de kısa formları aynı temsile dönüştürür ve önbellekteki tek biçimli gösterimi saklar. Bu nedenle, yerleşik denetleyiciler (birçok mobil platformda bulunanlar gibi) hız farkına sahip olurken, x86 tabanlı çoğu bilgisayar olmaz.

Ayrıca, bir döngünün içinde bir sabitin yoğun olarak kullanıldığı birçok durumda, bir derleyicinin sabiti sadece bir kez - döngü başlamadan önce - zamanlama farklılıkları oluşturmada bir yükleyiciye yüklemesi gerekeceğini unutmayın. Öte yandan, küçük döngülerde bile, bunun her zaman olmayacağı bazı durumlar vardır; eğer bir ilmek küçük fakat yoğun bir şekilde yürütülürse, zaman zaman kısa anlık değerleri içeren ve uzun olanları içeren karşılaştırmalar arasında büyük bir performans olabilir.

Bu sorunun kısa cevabı, hayır , aynı veri tipinde saklandıklarını varsayarak bu sayıların büyüklüğüne dayanarak iki sayıyı karşılaştırmak için zaman farkı yoktur (örn. Hem 32-bit inç veya her ikisi de 64-bit).

Dahası, ALU kelime büyüklüğüne kadar, iki tamsayının birbiriyle karşılaştırılmasının, bir çıkarma işlemine eşdeğer önemsiz bir işlem olduğu için 1 saatten daha fazla sürmesi inanılmaz bir ihtimal. Sanırım şimdiye kadar ele aldığım her mimarın tek çevrim tam sayı karşılaştırması vardı.

İki sayının karşılaştırılmasının tek döngülü bir işlem olmadığı durumlarda karşılaştığımı düşünebildiğim tek vaka:

• İşlenenleri almada gerçekte bir bellek gecikmesi olduğu, ancak karşılaştırmanın nasıl çalıştığı ile ilgisi olmayan talimatlar (ve genellikle RISC mimarilerinde, ancak x86 / x64 gibi CISC tasarımlarında mümkün olsa da) ile ilgisi yoktur.
• Kayan nokta karşılaştırmaları, mimariye bağlı olarak çok döngülü olabilir.
• Söz konusu sayılar ALU’nun kelime boyutuna uymuyor ve bu nedenle karşılaştırma birden fazla talimatlara bölünmüş olmalı.

@ RobertHarvey'in cevabı iyidir; Bu cevabı onun için bir ek olarak düşünün.

Ayrıca Şube Tahminini de göz önünde bulundurmalısınız :

Bilgisayar mimarisinde, dal tahmincisi, kesin olarak bilinmeden önce bir dalın (örneğin, eğer öyleyse bir yapı) hangi yöne gideceğini tahmin etmeye çalışan bir dijital devredir. Branş tahmininin amacı, talimat boru hattındaki akışı iyileştirmektir. Şube tahmin edicileri, x86 gibi birçok modern boru hattı işlemcisi mimarisinde yüksek performans elde etmede kritik bir rol oynamaktadır.

Temel olarak, örneğinizde, ifdöngü içindeki ifade her zaman aynı cevabı verirse, sistem hangi şekilde dallanacağını doğru tahmin ederek en iyi duruma getirebilir. Örneğinizde if, ilk davadaki ifade her zaman aynı sonucu verdiğinden, ikinci davadan biraz daha hızlı çalışacaktır.

Konuyla ilgili Mükemmel Yığın Taşması sorusu

Bu uygulamaya bağlıdır, ancak çok, çok düşük bir ihtimaldir .

Çeşitli tarayıcı motorlarının uygulama ayrıntılarını okumadığımı itiraf ediyorum ve CSS, numaralar için belirli bir depolama türü belirtmediğini belirtti. Ancak, tüm büyük tarayıcıların CSS'deki sayısal ihtiyaçlarının çoğunu yerine getirmek için 64 bit çift duyarlıklı kayan nokta sayıları ("çiftler", C / C ++ 'dan bir terim ödünç almak için) kullandığını varsaymanın güvenli olduğuna inanıyorum. , çünkü bu numaralar için JavaScript'in kullandığı şeydir ve bu nedenle aynı türün kullanılması entegrasyonu kolaylaştırır.

Bilgisayarın bakış açısından, tüm iki katlar aynı miktarda veri taşır: değerin 1 veya -3.14 veya 1000000 veya 1e100 olup olmadığı 64 bit . Bu sayılar üzerinde işlem yapmak için geçen süre, bu sayıların gerçek değerine bağlı değildir, çünkü daima aynı miktarda veri üzerinde çalışır. İşlerin bu şekilde yapılması konusunda bir sapma vardır, çünkü çiftler tüm sayıları (veya aralarındaki tüm sayıları bile) doğru şekilde temsil edemezler, ancak çoğu mesele için yeterince yaklaşabilirler ve CSS'nin sayıları sayısal olarak değil Bundan daha fazla hassasiyete ihtiyaç duyacak kadar iddialıyım. Bunu, JavaScript ile doğrudan uyumlu olmanın avantajlarıyla birleştirin ve çiftler için oldukça güçlü bir durum elde edin.

Birinin numaralar için değişken uzunluklu bir kodlama kullanarak CSS yapması imkansız değildir. Birisi değişken uzunlukta kodlama kullandıysanız, o zaman çok sayıda crunch fazla veri var çünkü az sayıda karşı karşılaştırarak, büyük sayılar karşısında karşılaştırmaktan daha az pahalı olacaktır . Bu tür kodlamalar ikili dosyalardan daha kesin olabilir, ancak aynı zamanda çok daha yavaştır ve özellikle CSS için hassas kazançlar muhtemelen performansın düşmesi için yeterli değildir. Herhangi bir tarayıcının bu şekilde bir şey yaptığını öğrenmek çok şaşırırdım.

Şimdi, teoride, yukarıda söylediğim her şeyin olası bir istisnası var: sıfıra karşı karşılaştırma yapmak, genellikle diğer sayılara karşı karşılaştırma yapmaktan daha hızlıdır . Bunun sebebi sıfırın kısa olması değil (sebep buysa, o zaman 1 kadar hızlı olmalı, ama değil). Çünkü sıfır aldatmana izin veriyor. Tüm bitlerin kapalı olduğu tek sayıdır, yani değerlerden birinin sıfır olduğunu biliyorsanız, diğer değere bir sayı olarak bakmak zorunda kalmazsınız: eğer bitlerin herhangi biri eşit değilse sıfır, ve sıfırdan büyük mü yoksa küçük mü olduğunu görmek için yalnızca bir bit'e bakmak gerekir.

Bu kod her çalıştırıldığında yorumlanıyorsa, belirtmek ve yorumlamakla 10000000000000karşılaştırıldığında daha uzun sürdüğü için bir fark olacaktır 1000. Ancak, bu durumda tercümanların ilk açık optimizasyonudur: bir kez belirtmek ve belirteçleri yorumlamak.