Hızlı tamsayı türleri neden diğer tamsayı türlerinden daha hızlıdır?

ISO / IEC 9899: 2018'de (C18) 7.20.1.3'te belirtilmiştir:

7.20.1.3 En hızlı minimum genişlikli tamsayı türleri

1 Aşağıdaki türlerin her biri, en az belirtilen genişliğe sahip tüm tamsayı türleri arasında çalışmak için genellikle en hızlı olan bir tamsayı türünü belirtir ²⁶⁸⁾ .

2 typedef adı int_fastN_t, genişliği en az N olan en hızlı imzalı tamsayı türünü belirtir . Typedef adı , en az N genişliği olan en uint_fastN_thızlı işaretsiz tamsayı türünü belirtir.

3 Aşağıdaki türler gereklidir:

int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t, uint_fast32_t,uint_fast64_t

Bu formun diğer tüm türleri isteğe bağlıdır.

---

²⁶⁸⁾ Belirlenen türün her amaç için en hızlı olduğu garanti edilmez; uygulamanın bir türü diğerine göre seçmek için net bir temeli yoksa, yalnızca imza ve genişlik gereksinimlerini karşılayan bir tamsayı türü seçecektir.

Ancak bu "hızlı" tamsayı türlerinin neden daha hızlı olduğu belirtilmemiştir.

• Bu hızlı tamsayı türleri neden diğer tamsayı türlerinden daha hızlı?

  ---

_{Soruyu C ++ ile etiketledim, çünkü hızlı tamsayı türleri C ++ 17'de başlık dosyasında da mevcut cstdint. Ne yazık ki, ISO / IEC 14882: 2017'de (C ++ 17) açıklamaları hakkında böyle bir bölüm yoktur; Bu bölümü soru gövdesinde başka türlü uygulamıştım.}

Bilgi: C dilinde, başlık dosyasında bildirilir stdint.h.

Sadece 64 bit aritmetik işlemler yapan bir CPU düşünün. Şimdi böyle bir CPU'ya imzasız bir 8 bit eklemeyi nasıl uygulayacağınızı hayal edin. Doğru sonucu elde etmek için mutlaka birden fazla işlem yapılması gerekir. Bu tür CPU'larda, 64 bit işlemler diğer tamsayı genişliklerindeki işlemlerden daha hızlıdır. Bu durumda, hepsiXint_fastY_t 64 bit türünde bir takma ad olabilir.

CPU dar tamsayı türleri için hızlı işlemleri destekliyorsa ve bu nedenle daha geniş bir tip daha dar olandan daha hızlı değilse, Xint_fastY_t tüm Y bitlerini temsil etmek için gerekenden daha geniş bir türün diğer adı olmayacaktır.

Meraktan, bazı mimarilerde belirli bir uygulamanın (GNU, Linux) boyutlarını kontrol ettim. Bunlar, aynı mimari üzerindeki tüm uygulamalarda aynı değildir:

┌────╥───────────────────────────────────────────────────────────┐
│ Y  ║   sizeof(Xint_fastY_t) * CHAR_BIT                         │
│    ╟────────┬─────┬───────┬─────┬────────┬──────┬────────┬─────┤
│    ║ x86-64 │ x86 │ ARM64 │ ARM │ MIPS64 │ MIPS │ MSP430 │ AVR │
╞════╬════════╪═════╪═══════╪═════╪════════╪══════╪════════╪═════╡
│ 8  ║ 8      │ 8   │ 8     │ 32  │ 8      │ 8    │ 16     │ 8   │
│ 16 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 16     │ 16  │
│ 32 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 32     │ 32  │
│ 64 ║ 64     │ 64  │ 64    │ 64  │ 64     │ 64   │ 64     │ 64  │
└────╨────────┴─────┴───────┴─────┴────────┴──────┴────────┴─────┘

Daha büyük türlerdeki işlemler daha hızlı olabilse de, bu türlerin de önbellekte daha fazla yer kapladığını ve dolayısıyla bunları kullanmanın daha iyi performans sağlamayacağını unutmayın. Ayrıca, uygulamanın ilk etapta doğru seçimi yaptığına her zaman güvenilemez. Her zaman olduğu gibi, optimum sonuçlar için ölçüm gereklidir.

Android kullanıcıları için tablonun ekran görüntüsü:

^{(Android'in mono yazı tipinde kutu çizim karakterleri yoktur - ref )}

En azından güvenilir değiller.

Hızlı tipler normal tipler için typedefs'dir, ancak bunların nasıl tanımlanacağı uygulamaya bağlıdır. En azından istenen boyutta olmalılar, ancak daha büyük olabilirler.

Bazı mimarilerde bazı tamsayı türlerinin diğerlerinden daha iyi performans gösterdiği doğrudur. Örneğin, erken ARM uygulamalarında 32 bit sözcükler ve imzasız baytlar için bellek erişim talimatları vardı, ancak yarım sözcükler veya imzalı baytlar için talimatlar yoktu. Yarım sözcük ve imzalı bayt yönergeleri daha sonra eklenmiştir, ancak yedek kodlama alanına ayakkabı dolaştırılması gerektiğinden hala daha az esnek adresleme seçenekleri vardır. Ayrıca, ARM hakkındaki tüm gerçek veri işleme talimatları kelimeler üzerinde çalışır, bu nedenle bazı durumlarda doğru sonuçları vermek için hesaplamadan sonra daha küçük değerlerin maskelenmesi gerekebilir.

Bununla birlikte, daha küçük bir değer yüklemek / depolamak / işlemek için daha fazla talimat alsa bile, önbellek baskısının rekabet eden endişesi de vardır. Önbellek kaçırma sayısını azaltırsa daha küçük değer yine de daha iyi performans gösterebilir.

Birçok yaygın platformda tür tanımları düşünülmüş görünmemektedir. Özellikle, modern 64 bit platformlar 32 bit tamsayılar için iyi bir desteğe sahip olma eğilimindedir, ancak "hızlı" türler genellikle bu platformlarda gereksiz yere 64 bittir.

Ayrıca, C'deki türler platformun ABI'sinin bir parçası haline gelir. Bu nedenle, bir platform satıcısı aptal seçimler yaptığını fark etse bile, daha sonra bu aptal seçimleri değiştirmek zordur.

"Hızlı" türleri dikkate almayın. Tamsayı performansıyla ilgili endişeleriniz varsa, kodunuzu kullanılabilir tüm boyutlarla kıyaslayın.

Hızlı türler diğer tüm tamsayı türlerinden daha hızlı değildir - aslında bazı "normal" tamsayı türleriyle özdeştirler (sadece bu tür için bir takma addır) - hangi tür değeri tutmak için en hızlı olursa en azından bu kadar bit.

Her platforma hangi tamsayı türü için takma ad olduğu yalnızca platforma bağlıdır .