FIFO için hangi STL kabını kullanmalıyım?

Hangi STL kabı ihtiyaçlarımı en iyi şekilde karşılar? Temelde , en eski öğeyi (yaklaşık bir milyon kez) oluştururken içinde sürekli olarak push_backyeni öğeler içeren 10 öğe genişliğinde bir kabım var pop_front.

Şu anda bir kullanıyorum std::dequegörev için ancak eğer merak std::listBen kendisini yeniden tahsis etmek gerek olmazdı çünkü daha verimli olacaktır (ya da belki bir karıştırıyorsun ediyorum std::dequebir için std::vector?). Yoksa ihtiyacım için daha verimli bir konteyner var mı?

PS rastgele erişime ihtiyacım yok

Sayısız cevap olduğu için kafanız karışabilir, ancak özetlemek gerekirse:

Bir std::queue. Bunun nedeni basit: bir FIFO yapısıdır. FIFO istiyorsanız, bir std::queue.

Niyetinizi başkalarına ve hatta kendinize açık hale getirir. A std::listya std::dequeda değil. Bir liste herhangi bir yere eklenebilir ve kaldırılabilir, ki bu bir FIFO yapısının yapması gereken şey değildir ve bir dequeuçtan bir ekleyip çıkarabilir, ki bu da bir FIFO yapısının yapamayacağı bir şeydir.

Bu nedenle bir queue.

Şimdi, performansı sordun. İlk olarak, her zaman şu önemli kuralı hatırlayın: Önce iyi kod, sonra performans.

Bunun nedeni basit: Temizlik ve şıklıktan önce performans için çabalayan insanlar neredeyse her zaman en son bitiriyor. Kodları bir lapa haline gelir, çünkü ondan gerçekten hiçbir şey elde etmek için iyi olan her şeyi terk etmişlerdir.

Önce iyi, okunabilir kod yazarak, çoğunuz performans problemlerini kendiliğinden çözecektir. Ve daha sonra performansınızın yetersiz olduğunu fark ederseniz, artık güzel, temiz kodunuza bir profilleyici eklemek ve sorunun nerede olduğunu bulmak çok kolay.

Hepsi söylendi, std::queuesadece bir adaptör. Güvenli arayüz sağlar, ancak içeride farklı bir konteyner kullanır. Bu temel kapsayıcıyı seçebilirsiniz ve bu büyük ölçüde esneklik sağlar.

Peki hangi temel kapsayıcıyı kullanmalısınız? Bunu biliyoruz std::listve std::dequehem gerekli işlevleri sağlamak ( push_back(), pop_front()ve front()), bu yüzden nasıl karar vereceğiz?

İlk olarak, bellek ayırmanın (ve ayırmanın) genellikle yapılacak hızlı bir şey olmadığını anlayın, çünkü bu, işletim sistemine gidip ondan bir şey yapmasını istemeyi içerir. A list, her bir şey eklendiğinde bellek ayırmalı ve gittiğinde onu serbest bırakmalıdır.

dequeÖte yandan A , parçalar halinde tahsis eder. A'dan daha az sıklıkta ayıracaktır list. Bunu bir liste olarak düşünün, ancak her bellek parçası birden fazla düğümü tutabilir. (Elbette, nasıl çalıştığını gerçekten öğrenmenizi öneririm .)

Yani tek başına dequebununla daha iyi performans göstermelidir çünkü bellekle pek sık ilgilenmez. Sabit büyüklükteki verileri işlediğiniz gerçeğiyle karıştırıldığında, muhtemelen verilerden ilk geçişten sonra ayırmak zorunda kalmayacak, oysa bir liste sürekli olarak tahsis edecek ve serbest bırakacaktır.

Anlaşılması gereken ikinci bir şey de önbellek performansı . RAM'e çıkmak yavaştır, bu nedenle CPU gerçekten ihtiyaç duyduğunda, bir yığın belleği önbelleğe geri alarak bu zamandan en iyi şekilde yararlanır. dequeBellek yığınlarında bir ayırma olduğu için, bu kapsayıcıdaki bir öğeye erişmenin CPU'nun kabın geri kalanını da geri getirmesine neden olması muhtemeldir. Şimdi deque, veri önbellekte olduğu için başka erişim hızlı olacaktır.

Bu, verilerin teker teker tahsis edildiği bir listeden farklıdır. Bu, verilerin belleğin her yerine yayılabileceği ve önbellek performansının kötü olacağı anlamına gelir.

Bu nedenle, bunu göz önünde bulundurarak, dequea daha iyi bir seçim olmalıdır. Bu nedenle, bir queue. Tüm bunlarla birlikte, bu hala sadece (çok) eğitimli bir tahmin: Bu kodun profilini, dequebir testte a kullanarak ve listdiğerinde gerçekten kesin olarak bilmek zorunda kalacaksın .

Ancak unutmayın: kodu temiz bir arayüzle çalıştırın, ardından performans konusunda endişelenin.

John, a listveya sarmanın dequeperformans düşüşüne neden olacağı endişesini dile getiriyor . Bir kez daha, kendisinin profilini çıkarmadan kesin olarak söyleyemeyiz, ancak derleyicinin yaptığı çağrıları satır içi yapması ihtimali vardır queue. Yani, dediğinizde queue.push(), gerçekten sadece queue.container.push_back()işlev çağrısını tamamen atlayarak diyecektir .

Bir kez daha, bu yalnızca eğitimli bir tahmindir, ancak queuetemeldeki kapsayıcı ham kullanımına kıyasla a kullanmak performansı düşürmez. Daha önce de söylediğim gibi, queuetemiz, kullanımı kolay ve güvenli olduğu için ve gerçekten bir sorun profili ve testi haline gelirse, kullanın.

Kontrol edin std::queue. Temel bir kapsayıcı türünü sarar ve varsayılan kapsayıcı std::deque.

Performansın gerçekten önemli olduğu yerlerde, Boost dairesel arabellek kitaplığına göz atın .

En eski öğeyi oluştururken (yaklaşık bir milyon kez) sürekli olarak push_backyeni öğeler pop_front.

Hesaplamada bir milyon gerçekten büyük bir sayı değildir. Başkalarının da önerdiği std::queuegibi, ilk çözümünüz olarak a kullanın . Çok yavaş olması beklenmedik bir durumda, bir profil oluşturucu kullanarak darboğazı tanımlayın (tahmin etmeyin!) Ve aynı arayüze sahip farklı bir kapsayıcı kullanarak yeniden uygulayın.

Neden olmasın std::queue? Sahip olduğu tek şey push_backve pop_front.

Bir kuyruk muhtemelen daha basit bir arayüz deque ama böyle küçük bir listesi için, performans farkı muhtemelen önemsiz.

Aynı liste için de geçerli . Bu, istediğiniz API'ye bağlı.

A kullanın std::queue, ancak iki standart Containersınıfın performans ödünleşmelerinin farkında olun .

Varsayılan olarak, std::queueüstünde bir adaptördür std::deque. Tipik olarak, çok sayıda giriş içeren az sayıda kuyruğa sahip olduğunuzda iyi performans sağlar ki bu muhtemelen yaygın bir durumdur.

Bununla birlikte, std :: deque uygulamasına kör olmayın . Özellikle:

"... dekorlar tipik olarak büyük minimum bellek maliyetine sahiptir; sadece bir öğeyi tutan bir geri çekilme, tüm dahili dizisini tahsis etmek zorundadır (örneğin, 64 bit libstdc ++ 'da nesne boyutunun 8 katı; nesne boyutunun 16 katı veya 4096 bayt, hangisi daha büyükse , 64 bit libc ++ üzerinde). "

Bunu netleştirmek için, bir kuyruk girişinin sıraya koymak isteyeceğiniz bir şey olduğunu varsayarsak, yani boyut olarak oldukça küçükse, her biri 30.000 giriş içeren 4 kuyruğunuz varsa, std::dequeuygulama tercih edilen seçenek olacaktır. Tersine, her biri 4 giriş içeren 30.000 kuyruğunuz varsa , bu senaryoda ek yükü std::listasla amorti etmeyeceğiniz için uygulama büyük olasılıkla optimal olacaktır std::deque.

Önbelleğin ne kadar kral olduğu, Stroustrup'un bağlantılı listelerden nasıl nefret ettiği vb. Hakkında birçok fikir okuyacaksınız ve bunların hepsi belirli koşullar altında doğru. Sadece körü körüne inanarak kabul etmeyin, çünkü oradaki ikinci senaryomuzda, varsayılan std::dequeuygulamanın çalışması pek olası değildir . Kullanımınızı değerlendirin ve ölçün.

Bu dava yeterince basittir ki kendi yazınızı yazabilirsiniz. STL kullanımının çok fazla yer kapladığı mikro denetleyici durumları için iyi çalışan bir şey burada. Veri ve sinyali kesme işleyicisinden ana döngünüze iletmenin güzel bir yolu.

// FIFO with circular buffer
#define fifo_size 4

class Fifo {
  uint8_t buff[fifo_size];
  int writePtr = 0;
  int readPtr = 0;
  
public:  
  void put(uint8_t val) {
    buff[writePtr%fifo_size] = val;
    writePtr++;
  }
  uint8_t get() {
    uint8_t val = NULL;
    if(readPtr < writePtr) {
      val = buff[readPtr%fifo_size];
      readPtr++;
      
      // reset pointers to avoid overflow
      if(readPtr > fifo_size) {
        writePtr = writePtr%fifo_size;
        readPtr = readPtr%fifo_size;
      }
    }
    return val;
  }
  int count() { return (writePtr - readPtr);}
};