Aritmetik Taşma neden ihmal edilir?

Hiç favori programlama dilinizdeki 1 ila 2.000.000 arasındaki tüm sayıları toplamaya çalıştınız mı? Sonuç elle hesaplamak kolaydır: işaretsiz bir 32bit tamsayının maksimum değerinden 900 kat daha büyük olan 2,000,001,000,000.

C # yazdırır -1453759936- negatif bir değer! Ve sanırım Java da aynı şeyi yapıyor.

Bu, varsayılan olarak Aritmetik Taşma'yı görmezden gelen bazı ortak programlama dilleri olduğu anlamına gelir (C # dilinde, bunu değiştirmek için gizli seçenekler vardır). Bu benim için çok riskli görünen bir davranış ve bu tür bir taşma nedeniyle Ariane 5'in çöküşü değil miydi?

Öyleyse: Böylesine tehlikeli bir davranışın arkasındaki tasarım kararları nelerdir?

Düzenle:

Bu sorunun ilk cevapları, aşırı kontrol maliyetlerini ifade ediyor. Bu varsayımı test etmek için kısa bir C # programı çalıştıralım:

Stopwatch watch = Stopwatch.StartNew();
checked
{
    for (int i = 0; i < 200000; i++)
    {
        int sum = 0;
        for (int j = 1; j < 50000; j++)
        {
            sum += j;
        }
    }
}
watch.Stop();
Console.WriteLine(watch.Elapsed.TotalMilliseconds);

Makinemde işaretli sürüm 11015ms, denetlenmeyen sürüm 4125ms. Diğer bir deyişle, kontrol adımları numaraların eklenmesiyle neredeyse iki katına çıkar (toplamda orijinal sürenin 3 katı). Ancak 10.000.000.000 tekrarla, çekle geçen zaman hala 1 nanosaniyeden az. Bunun önemli olduğu bir durum olabilir, ancak çoğu uygulama için bunun önemi yoktur.

Düzenleme 2:

Sunucu uygulamamızı (birkaç sensörden gelen verilerin analizini yapan bir Windows servisi, oldukça fazla sayıda kırılmaya neden oldu) /p:CheckForOverflowUnderflow="false"parametre ile (normalde taşma kontrolünü açtım) yeniden derledim ve bir cihaza yerleştirdim. Nagios izleme, ortalama CPU yükünün% 17'de kaldığını gösteriyor.

Bu, yukarıdaki telafi örneğinde bulunan performans isabetinin uygulamamızla tamamen alakasız olduğu anlamına gelir.

Bunun 3 nedeni var:

1. Çalışma süresinde taşma kontrolü (her bir aritmetik işlem için) fazladır.

2. Derleme zamanında bir taşma kontrolünün atlanabileceğini kanıtlamanın karmaşıklığı aşırıdır.

3. Bazı durumlarda (örneğin, CRC hesaplamaları, çok sayıda kitaplık, vb.) "Taşma sarması" programcılar için daha uygundur.

Kötü bir tradeoff olduğunu kim söylüyor?

Tüm üretim uygulamalarımı taşma kontrolü etkin olarak çalıştırıyorum. Bu bir C # derleyici seçeneğidir. Aslında bunu kıyaslamıştım ve farkı belirleyemedim. Veritabanına (oyuncak olmayan) HTML oluşturmak için erişmenin maliyeti, taşma kontrol maliyetlerini aşmaktadır.

Üretimde hiçbir işlem taşması olmadığını bildiğim için teşekkür ederim . Hemen hemen tüm kodlar taşma varlığında hatalı davranır. Böcekler iyi huylu olmazdı. Veri bozulması muhtemeldir, güvenlik olasılığı vardır.

Performansa ihtiyacım olursa, ki bu bazen böyle olur, unchecked {}ayrıntılı bir şekilde kullanarak taşma kontrolünü devre dışı bırakırım . Taşmayan bir işleme güvendiğimi söylemek checked {}istediğimde, bu gerçeği belgelemek için fazladan kod ekleyebilirim . Taşma konusunda dikkatliyim, ancak kontrol için mutlaka olmama gerek yok.

Onlar seçti zaman C # takımı yanlış bir seçim yapılmış inanmak değil , varsayılan olarak taşma kontrol ama bu seçim artık güçlü uyumluluk endişeleri nedeniyle kapatılır. Bu seçimin 2000 yılı civarında yapıldığını unutmayın. Donanım daha az yetenekliydi ve .NET'in henüz çok fazla çekişi yoktu. Belki .NET, Java ve C / C ++ programcılarına bu şekilde itiraz etmek istedi. .NET aynı zamanda metale yakın olabilmek içindir. Bu yüzden güvensiz kodlara, yapılara ve hepsi Java'nın sahip olmadığı mükemmel yerel çağrı yeteneklerine sahiptir.

Donanımımız ne kadar hızlı olursa, daha akıllı derleyiciler varsayılan olarak daha çekici taşma kontrolü elde eder.

Ayrıca taşma kontrolünün genellikle sonsuz büyüklükteki sayılardan daha iyi olduğuna inanıyorum. Sınırsız büyüklükteki rakamlar daha da yüksek, optimize edilmesi zor (inanıyorum) bir performans maliyetine sahip ve sınırsız kaynak tüketimi olasılığını başlatıyorlar.

JavaScript'in taşma ile başa çıkma şekli daha da kötüdür. JavaScript numaraları kayan nokta iki katına çıkar. Bir "taşma", tam olarak tam sayı kümesini bırakmak olarak kendini gösterir. Hafifçe yanlış sonuçlar ortaya çıkacaktır (örneğin, biri tarafından kapalı olma - bu, sonlu döngüleri sonsuz sonuçlara dönüştürebilir).

C / C ++ gibi bazı diller için, varsayılan olarak taşma kontrolü kesinlikle uygun değildir, çünkü bu dillerde yazılmış uygulamaların çıplak metal performansına ihtiyacı vardır. Yine de, izin vererek daha güvenli bir dile C / C ++ yapmak için çabalar var seçmesi daha güvenli moduna. Kodun% 90-99'u soğuk olma eğiliminde olduğundan bu övgüye değer. Bir örnek fwrapv2'nin tamamlayıcı paketlemesini zorlayan derleyici seçeneğidir. Bu, derleyici tarafından değil, dilin "uygulama kalitesi" özelliğidir.

Haskell'in mantıksal arama yığını yok ve belirtilen değerlendirme sırası yok. Bu, öngörülemeyen noktalarda istisnalar meydana getirir. Gelen a + bolsun belirtilmemiş ise aveya bilk değerlendirilir ve bu ifadelerin hepsi ya da hiç sonlandırmak ister. Bu nedenle, Haskell'in çoğu zaman sınırsız tamsayı kullanması mantıklıdır. Bu seçenek tamamen işlevsel bir dil için uygundur, çünkü istisnalar çoğu Haskell kodunda gerçekten uygun değildir. Ve sıfıra bölmek gerçekten de Haskells dil tasarımında sorunlu bir nokta. Sınırlandırılmamış tamsayılar yerine, sabit genişlikte sarma tamsayıları da kullanabilirlerdi ancak bu, dilin sunduğu “doğruluk odağı” temasına uymuyordu.

Taşma istisnalarına bir alternatif, tanımlanmamış işlemler tarafından oluşturulan ve işlemler arasında yayılan zehir değerleridir (değişken NaNdeğer gibi ). Bu, taşma kontrolünden çok daha pahalı gibi görünmekte ve tüm işlemleri sadece yavaşlayabilenlere değil daha da yavaşlatmaktadır (genellikle yüzer ve genel olarak sahip olan donanım ivmesini engellemekle sık sık olmaz - Itanium "Bir Şey Değil" olan NaT'ye sahiptir ). Ayrıca programın kötü verilerle birlikte aksamaya devam etmesinin bir noktasını da göremiyorum. Gibi ON ERROR RESUME NEXT. Hataları gizler ancak doğru sonuçların alınmasına yardımcı olmaz. supercat, bazen bunu yapmanın bir performans optimizasyonu olduğuna işaret ediyor.

Bunu yapmak için kötü bir değiş tokuş Çünkü bütün otomatik bir taşma nadir durumda yakalamak için hesaplamalar çok daha pahalı yapar meydana gelir. Programcının, bunun bir sorun olduğu nadir durumları kabul etmesi ile yüklenmesi ve tüm programcıların kullanmadıkları işlevsellik için bedel ödemesinden daha fazla özel engeller eklemeleri çok daha iyidir .

Böyle tehlikeli bir davranış arkasındaki tasarım kararları nelerdir?

"Kullanıcıları ihtiyaç duymadıkları bir özellik için performans cezası vermeye zorlamayın."

C ve C ++ tasarımındaki en temel prensiplerden biridir ve günümüzde önemsiz sayılan işler için zorlukla yeterli performans elde etmek için gülünç sıkışıklıklar yaşamanız gereken farklı zamanlardan kaynaklanmaktadır.

Yeni diller, dizi sınırları denetimi gibi diğer birçok özellik için bu tutumu kırmaktadır. Taşma kontrolü için neden yapmadıklarından emin değilim; Bu sadece bir gözetim olabilir.

miras

Bu sorunun muhtemelen eskiden kaynaklandığını söyleyebilirim. C’de:

• İmzalı taşma tanımsız davranış (derleyicilerin sarılmasını sağlamak için destek bayraklarını destekler),
• işaretsiz taşma tanımlanmış davranış (sarar).

Bu, programcının ne yaptığını bildiği ilkesini izleyerek mümkün olan en iyi performansı elde etmek için yapıldı .

Statu-Quo'ya Giden Yol

C'nin (ve C ++ uzantısına göre) sırayla taşma algılamasını gerektirmemesi, taşma kontrolünün durgun olduğu anlamına gelir.

Donanım çoğunlukla C / C ++ 'a hitap eder (ciddi olarak, x86'nın bir strcmptalimatı vardır (aka SSE 4.2'den beri PCMPISTRI )!) Ve C umursamadığından, yaygın CPU'lar taşma tespit etmede etkili yollar sunmaz. X86'da, her taşma işleminden sonra çekirdek başına bir bayrağını kontrol etmeniz gerekir; gerçekte istediğin şey, sonuçta "lekeli" bir bayrak olduğunda (NaN'in çoğaldığı gibi). Ve vektör işlemleri daha problemli olabilir. Bazı yeni oyuncular piyasada verimli taşma işlemleriyle görünebilir; ama şimdilik x86 ve ARM umursamıyor.

Derleyici iyileştiricileri, taşma kontrollerini optimize etmede veya hatta taşma varlığında optimize etmede iyi değildir. John Regher gibi bazı akademisyenler bu statüden şikayetçidir , ancak gerçek şu ki, "başarısızlıklar" yapmanın basit gerçeği, montaj işlemine başlamadan bile optimizasyonları engelliyor olabilir. Özellikle otomatik vektörleşmeyi önlediğinde ...

Basamaklı efektlerle

Bu nedenle, verimli optimizasyon stratejileri ve verimli CPU desteği yoksa, taşma kontrolü maliyetlidir. Kaydırmaktan çok daha pahalı.

x + y - 1Olmadığında taşma gibi bazı rahatsız edici davranışlar ekleyin, bu x - 1 + ykullanıcılar yasal olarak rahatsız edebilir ve taşma kontrolü genellikle sarma lehine atılır (bu örneği ele alır).

Yine de bütün umutlar kaybolmaz

Clang ve gcc derleyicilerinde "dezenfektanlar" uygulamak için gayret gösterildi: Tanımsız Davranış vakalarını saptamak için enstrüman ikili araçlarını kullanma yolları. Kullanırken -fsanitize=undefined, işaretli taşma algılanır ve programı iptal eder; test sırasında çok faydalıdır.

Pas programlama dili etkin taşma denetimine sahip varsayılan olarak hata ayıklama modunda (bu performans nedenleriyle yayın modunda aritmetik sarma kullanır).

Bu nedenle, taşma kontrolü ve sahte sonuçların tehlikelerinin tespit edilememesi konusunda artan endişeler var ve umarım bu, araştırma topluluğuna, derleyici topluluğuna ve donanım topluluğuna olan ilgiyi artıracaktır.

Taşmaları algılamaya çalışan diller, tarihsel olarak ilgili semantiği, başka türlü yararlı optimizasyon olabilecekleri ciddi şekilde kısıtlayan yollarla tanımlamıştır. Diğer şeylerin yanı sıra, hesaplamaları kodda belirtilenden farklı bir sırayla yapmak çoğu zaman yararlı olacaktır, ancak taşma tuzakları çoğu dilde verilen kodda belirtilenleri garanti eder:

for (int i=0; i<100; i++)
{
  Operation1();
  x+=i;
  Operation2();
}

x'in başlangıç ​​değeri, döngü boyunca 47. geçişte bir taşma meydana gelirse, İşlem1 47 defa yürütülür ve İşlem2 46 gerçekleştirilir. Operation1 veya Operation2 tarafından verilen bir istisnayı takiben x değerini kullanacak, kod aşağıdakilerle değiştirilebilir:

x+=4950;
for (int i=0; i<100; i++)
{
  Operation1();
  Operation2();
}

Ne yazık ki, döngü içinde taşma meydana geldiği durumlarda doğru semantiği garanti ederken bu gibi optimizasyonları yapmak zordur - esasen şöyle bir şey gerektirir:

if (x < INT_MAX-4950)
{
  x+=4950;
  for (int i=0; i<100; i++)
  {
    Operation1();
    Operation2();
  }
}
else
{
  for (int i=0; i<100; i++)
  {
    Operation1();
    x+=i;
    Operation2();
  }
}

Bir çok gerçek dünya kodunun daha ilgili döngüler kullandığı düşünülürse, taşma anlambilimini korurken kodu optimize etmenin zor olduğu açıktır. Ayrıca, önbelleğe alma sorunları nedeniyle, kod boyutundaki artışın, genel olarak yürütülen yolda daha az işlem olsa bile, genel programı daha yavaş çalışmasına olanak vermesi tamamen mümkündür.

Taşma algılamasını ucuz hale getirmek için ihtiyaç duyulacak olan, sonuçların (*), yükü etkilemeden taşma olmadan bir hesaplamanın yapılıp yapılmadığını rapor etmeyi kolaylaştıracak tanımlanmış bir gevşek taşma saptama semantiği kümesi olacaktır. bunun ötesinde ayrıntılarla derleyici. Bir dil belirtimi taşma tespitinin maliyetini yukarıdakileri elde etmek için gereken minimum düzeye indirmeye odaklanmışsa, mevcut dillerden olduğundan daha az maliyetli olabilir. Bununla birlikte, verimli taşma tespitini kolaylaştırmaya yönelik herhangi bir çabanın farkında değilim.

(*) Eğer bir dil tüm taşmaların bildirileceğini vaat ederse, o zaman böyle bir ifade taşma garantisi verilmediği sürece x*y/ybasitleştirilemez . Aynı şekilde, bir hesaplamanın sonucu göz ardı edilse bile, tüm taşmaları bildirmeyi vaat eden bir dilde, taşma kontrolünü yapabilmesi için yine de gerçekleştirmesi gerekecektir. Bu gibi durumlarda taşma aritmetik olarak yanlış davranışa yol açamadığından, bir taşma olasılığının yanlış sonuçlara neden olmadığından emin olmak için bir programın bu tür kontrolleri yapması gerekmez.xx*y

Bu arada, C'deki taşmalar özellikle kötüdür. Her ne kadar C99'ı destekleyen hemen hemen her donanım platformu ikinin tamamlayıcı sessiz sarma anlambilimini kullanıyor olsa da, modern derleyiciler için taşma durumunda rasgele yan etkilere neden olabilecek kodlar üretmek modadır. Örneğin, şöyle bir şey verilir:

#include <stdint.h>
uint32_t test(uint16_t x, uint16_t y) { return x*y & 65535u; }
uint32_t test2(uint16_t q, int *p)
{
  uint32_t total=0;
  q|=32768;
  for (int i = 32768; i<=q; i++)
  {
    total+=test(i,65535);
    *p+=1;
  }
  return total;
}

GCC, test2 için koşulsuz olarak bir kez (* p) artış yapan ve q içine verilen değerden bağımsız olarak 32768 döndüren kod üretecektir. Akıl yürütmesiyle, (32769 * 65535) & 65535u hesaplaması taşmaya neden olur ve bu nedenle derleyicinin (q | 32768) 32768'den daha büyük bir değer vereceği durumları dikkate almasına gerek yoktur. (32769 * 65535) ve 65535u hesaplamasının sonucun üst bitlerine dikkat etmesinin gerekmesi nedeniyle, gcc döngüyü yok saymak için gerekçe olarak işaretli taşma kullanacaktır.

Tüm programlama dilleri tamsayı taşmalarını dikkate almaz. Bazı diller, tüm sayılar (çoğu Lisp lehçeleri, Ruby, Smalltalk, ...) ve diğer kütüphaneler için güvenli tamsayı işlemleri sağlar; örneğin, C ++ için çeşitli BigInt sınıfları vardır.

Bir dilin varsayılan olarak tamsayıyı taşmasından güvenli yapıp yapmamasının amacı, amacına bağlıdır: C ve C ++ gibi sistem dillerinin sıfır maliyet soyutlaması sağlaması gerekir ve "büyük tamsayı" bir değildir. Ruby gibi üretkenlik dilleri kutudan büyük tam sayılar sağlayabilir ve yapabilir. Aralarında bir yerde olan Java ve C # gibi diller, IMHO'nun kutudan çıkardığı güvenli tamsayılarla gitmesi gerekir.

Gösterdiğiniz gibi, varsayılan olarak etkinleştirilmiş taşma kontrolleri varsa C # 3 kat daha yavaş olacaktır (örneğinizin bu dil için tipik bir uygulama olduğu varsayılarak). Performansın her zaman en önemli özellik olmadığına katılıyorum, ancak diller / derleyiciler tipik olarak tipik görevlerdeki performanslarıyla karşılaştırılıyor. Bu kısmen, dil özelliklerinin kalitesinin bir dereceye kadar öznel olmasından ve performans testinin objektif olmasından kaynaklanmaktadır.

Çoğu durumda C # 'ya benzeyen ancak 3 kat daha yavaş yeni bir dil tanıtırsanız, son kullanıcılarınızın çoğu taşma kontrollerinden daha fazla faydalansalar bile, pazar payı almak kolay olmazdı. yüksek performanstan.

Performansa dayalı taşma kontrol eksikliğini haklı çıkaran birçok cevabın ötesinde, dikkate alınması gereken iki farklı aritmetik türü vardır:

1. indeksleme hesaplamaları (dizi indeksleme ve / veya işaretçi aritmetiği)

2. diğer aritmetik

Dil, işaretçi boyutuyla aynı olan bir tamsayı boyutu kullanıyorsa, iyi oluşturulmuş bir program, dizin oluşturma hesaplamalarını taşması nedeniyle taşmayacaktır, çünkü dizin oluşturma hesaplamalarının taşmasına neden olması için mutlaka bellek tükenmesi gerekir.

Bu nedenle, ayırıcı veri yapılarını içeren işaretçi aritmetik ve indeksleme ifadeleriyle çalışırken bellek ayırmalarını kontrol etmek yeterlidir. Örneğin, 32 bitlik bir adres alanınız varsa ve 32 bitlik tamsayılar kullanıyorsanız ve maksimum 2GB'lık bir yığın tahsis edilmesine izin veriyorsa (adres alanının yaklaşık yarısı), indeksleme / işaretçi hesaplamaları (temel olarak) taşmaz.

Ayrıca, toplama / çıkarma / çarpmanın ne kadarının dizi indeksleme veya işaretçi hesaplaması içerdiğini ve böylece ilk kategoriye girdiğini görünce şaşırabilirsiniz. Nesne işaretçisi, sahaya erişim ve dizi manipülasyonları indeksleme işlemleridir ve birçok program bunlardan daha fazla aritmetik işlem yapmaz! Temel olarak, bu, programların tamsayı taşması kontrolü olmadan yaptıkları gibi çalışmasının birincil nedenidir.

Tüm indeksleme yapmayan ve imleme yapmayan hesaplamalar, ya taşma isteyenler / beklemekte olanlar (örneğin karma hesaplamalar) ve istemeyenler (örneğin, özetleme örneğiniz) olarak sınıflandırılmalıdır.

İkinci durumda, programcılar sıklıkla doubleveya bazıları gibi alternatif veri türlerini kullanır BigInt. Çoğu hesaplama , örneğin finansal hesaplamalar decimalyerine bir veri türü gerektirir double. Tamsayı tipleri ile yapışmazlar ve yapışmazlarsa, tamsayı taşmalarını kontrol etmeye özen göstermeleri gerekir - veya başka bir deyişle, evet, program belirttiğiniz gibi tespit edilemeyen bir hata durumuna ulaşabilir.

Programcılar olarak, sayısal veri tiplerindeki seçimlerimize ve bunların taşma olasılıkları bakımından sonuçlarına duyarlılıktan duyarlı olmamız gerekir. Genel olarak (ve özellikle hızlı tam sayı türlerini kullanma arzusu olan C dilleri ailesiyle çalışırken), indeksleme hesaplamaları ile diğerleri arasındaki farkların farkında olmamız gerekir.

Rust dili , hata ayıklama yapısı için çekler ekleyerek ve optimize edilmiş sürüm sürümünde bunları kaldırarak taşma olup olmadığını denetleme arasında ilginç bir uzlaşma sağlar. Bu, son sürümde hala tam performans elde ederken test sırasında hataları bulmanızı sağlar.

Taşma sargısı bazen istenen davranış olduğu için , işleçlerin taşma için denetlemediği sürümleri de vardır .

Değişiklik için RFC'deki seçimin arkasındaki neden hakkında daha fazla bilgi edinebilirsiniz . Bu blog yazısında , bu özelliğin yakalanmasına yardımcı olduğu hataların bir listesi de dahil olmak üzere birçok ilginç bilgi bulunmaktadır .

Swift'de, herhangi bir tamsayı taşması varsayılan olarak algılanır ve programı anında durdurur. Silme davranışına ihtiyaç duyduğunuz durumlarda, bunu başarabilen farklı operatörler & +, & - ve & * vardır. Bir işlem gerçekleştiren ve taşma olup olmadığını söyleyen işlevler de var.

Yeni başlayanların Collatz sırasını değerlendirmeye ve kod çökmesine neden olmaya çalışırken izlemek eğlenceli…

Şimdi Swift tasarımcıları da LLVM ve Clang tasarımcılarıdır, bu yüzden optimizasyon hakkında bir iki veya iki şey biliyorlar ve gereksiz taşma kontrollerinden kaçınılabilecek kapasiteye sahipler. Tüm optimizasyonlar etkinken, taşma kontrolü kod boyutuna ve yürütme süresine fazla bir şey katmaz. Ve taşmaların çoğu kesinlikle yanlış sonuçlara yol açtığından, kod boyutu ve iyi harcanan yürütme süresidir.

PS. C, C ++ 'da, Objective-C işaretli tamsayı aritmetik taşması tanımsız davranıştır. Bu, derleyicinin imzalı tamsayı taşması durumunda ne yaptığını, tanım gereği doğru olduğu anlamına gelir. İmzalı tamsayı taşmasıyla başa çıkmanın tipik yolları, CPU'nun size verdiği sonucu alarak, derleyiciye bu taşma olayının asla gerçekleşmeyeceği varsayımlarını oluşturmak (ve örneğin n + 1> n'nin her zaman doğru olduğu sonucuna varmaktır). asla olmadığı varsayılmıştır) ve nadiren kullanılan bir olasılık, Swift'in yaptığı gibi taşma olursa kontrol etmek ve çarpmaktır.

Aslında, bunun asıl nedeni tamamen teknik / tarihseldir: İşlemcinin çoğu için işareti yoksayması . Genellikle kayıtlara iki tamsayı eklemek için tek bir komut vardır ve CPU bu iki tamsayıyı imzalı veya imzasız olarak yorumlayıp yorumlamamanı umursamıyor. Aynısı çıkarma için ve hatta çarpma için de geçerlidir. İşaret farkında olması gereken tek aritmetik işlem bölünmedir.

Bunun işe yaramasının nedeni, 2'nin neredeyse tüm CPU'lar tarafından kullanılan işaretli tam sayıların tamamlayıcısı olarak gösterilmesidir. Örneğin, 4-bit 2'lerde 5 ve -3 eklenmesi buna benzer:

  0101   (5)
  1101   (-3)
(11010)  (carry)
  ----
  0010   (2)

Sarma ucunu atma davranışının doğru işaretli sonucu nasıl verdiğini gözlemleyin. Benzer şekilde, CPU'lar genellikle çıkarma işlemini x - yşu şekilde gerçekleştirir x + ~y + 1:

  0101   (5)
  1100   (~3, binary negation!)
(11011)  (carry, we carry in a 1 bit!)
  ----
  0010   (2)

Bu, donanımın eklenmesi olarak çıkarma işlemini gerçekleştirir, sadece aritmetik-mantıksal birime (ALU) girişleri önemsiz şekillerde düzenler. Daha basit ne olabilir?

Çarpma, bir toplama dizisinden başka bir şey olmadığından, benzer şekilde güzel davranır. 2'nin tamamlayıcı gösterimini kullanmanın ve aritmetik işlemlerin yapılmamasını ihmal etmenin sonucu basitleştirilmiş devre ve basitleştirilmiş komut kümeleridir.

Açıkçası, C metale yakın çalışmak üzere tasarlandığından, bu imzasız aritmetiğin standardize edilmiş davranışı ile aynı davranışı benimsemiş, sadece imzasız aritmetiğin tanımsız davranış vermesi için izin vermiştir. Ve bu seçim Java gibi diğer dillere ve tabii ki C # 'ya da taşındı.

Bazı cevaplar kontrolün maliyetini tartıştı ve bunun makul bir gerekçe olduğu konusunda tartışmak için cevabınızı düzenlediniz. Bu noktaları ele almaya çalışacağım.

C ve C ++ 'da (örnek olarak), dil tasarım ilkelerinden biri, istenmeyen bir işlevsellik sağlamak değildir. Bu genellikle "kullanmadığınız şey için ödeme yapmayın" ifadesiyle özetlenir. Programcının taşma kontrolü yapması isteniyorsa, bunu isteyebilir (ve cezayı ödeyebilir). Bu, dili kullanımı daha tehlikeli hale getirir, ancak bunu bilen bir dille çalışmayı tercih edersiniz, bu nedenle riski kabul edersiniz. Bu riski istemiyorsanız veya güvenliğin en üst düzeyde performans gösterdiği bir kod yazıyorsanız, performans / risk değişiminin farklı olduğu daha uygun bir dil seçebilirsiniz.

Ancak 10.000.000.000 tekrarla, çekle geçen zaman hala 1 nanosaniyeden az.

Bu akıl yürütmede yanlış olan birkaç şey var:

1. Bu çevreye özgüdür. Bunun gibi belirli rakamları alıntılamak genellikle çok az anlamlıdır, çünkü kod, performanslarına göre büyüklük derecelerine göre değişen her türlü ortam için yazılmıştır. Masaüstü bir makinedeki 1 nanosaniyeniz, yerleşik bir çevreyi kodlayan birine inanılmaz derecede hızlı gelebilir ve süper bir bilgisayar kümesi için kodlayan birine inanılmaz derecede yavaş görünebilir.

2. 1 nanosaniye, nadiren çalışan bir kod parçası için hiçbir şey gibi görünmeyebilir. Öte yandan, kodun ana işlevi olan bazı hesaplamaların iç döngüsünde ise, tıraş edebileceğiniz zamanın her bir kesimi büyük bir fark yaratabilir. Bir kümede bir simülasyon çalıştırıyorsanız, o zaman iç döngüde bir nanosaniyenin kaydedilen fraksiyonları doğrudan donanım ve elektrik için harcanan paraya çevrilebilir.

3. Bazı algoritmalar ve bağlamlar için, 10.000.000.000 yineleme önemsiz olabilir. Yine, yalnızca belirli bağlamlarda uygulanan belirli senaryolar hakkında konuşmak genellikle mantıklı değildir.

Bunun önemli olduğu bir durum olabilir, ancak çoğu uygulama için bunun önemi yoktur.

Belki de haklısın. Fakat yine de, bu, belirli bir dilin hedeflerinin ne olduğu ile ilgilidir. Aslında birçok dil "çoğu" nun gereksinimlerini karşılamak veya diğer kaygılara karşı güvenliği artırmak için tasarlanmıştır. C ve C ++ gibi diğerleri verime öncelik veriyor. Bu bağlamda, çoğu insanın canını sıkmayacağından, herkesin performans cezası ödemesini sağlamak, dilin elde etmeye çalıştığı şeye aykırıdır.

İyi cevaplar var, ama bence burada cevapsız bir nokta var: bir tamsayı taşmasının etkileri mutlaka kötü bir şey değildir ve bundan sonra bir varlık taşması sorunundan mı ikaynaklandığını bilmek güçtür. veya eğer kasıtlı olarak -1 ile çarpılarak yapıldıysa.MAX_INTMIN_INT

Örneğin, 0'dan büyük tüm temsil edilebilir tamsayıları bir arada eklemek istersem, sadece bir for(i=0;i>=0;++i){...}toplama döngüsü kullanırdım - ve taşması durumunda, bu, hedef davranışı olan (bir hata atmak, atlamak zorunda kalacağım anlamına gelir) ilaveyi durdurur. keyfi bir koruma çünkü standart aritmetik ile etkileşime giriyor). İlkel aritmetik kısıtlamak için kötü bir uygulama, çünkü:

• Her şeyde kullanılırlar - ilkel matematikteki bir yavaşlama her işleyen programda bir yavaşlamadır
• Bir programcının onlara ihtiyacı varsa, bunları daima ekleyebilir
• Onlara sahipseniz ve programcı onlara ihtiyaç duymuyorsa (ancak daha uzun çalışma sürelerine ihtiyaç duyuyorsa), optimizasyon için onları kolayca kaldıramazlar
• Onlara sahip ve programcı bunları ihtiyacı varsa değil (yukarıdaki örnekte olduğu gibi) olması, programcı her ikisi (veya ilgili olabilir veya olmayabilir) çalışma zamanı isabet alarak ve programcı hala çıkarmadan zaman harcaması gerekiyor veya “koruma” etrafında çalışmak.