Який контейнер STL слід використовувати для FIFO?

Який контейнер STL найкраще відповідав би моїм потребам? В основному я маю контейнер із 10 елементами ширини, в якому я постійно створюю push_backнові елементи, pop_frontпереглядаючи найстаріший елемент (приблизно мільйон разів).

В даний час я використовую a std::dequeдля цього завдання, але мені було цікаво, чи a std::listбуде більш ефективним, оскільки мені не потрібно буде перерозподіляти себе (або, можливо, я приймаю std::dequea std::vector?). Або є ще більш ефективний контейнер для моїх потреб?

PS Мені не потрібен довільний доступ

Оскільки відповідей існує безліч, ви можете заплутатися, але підсумовуючи:

Використовуйте a std::queue. Причина цього проста: це структура FIFO. Ви хочете FIFO, ви використовуєте std::queue.

Це дає зрозуміти ваші наміри будь-кому іншому, і навіть вам самим. А std::listчи std::dequeні. Список можна вставляти та видаляти де завгодно, чого не слід робити структурі FIFO, а dequeможна додавати та видаляти з будь-якого кінця, що також не може робити структура FIFO.

Ось чому вам слід використовувати a queue.

Тепер ви запитали про продуктивність. По-перше, завжди пам’ятайте про це важливе правило: спочатку хороший код, остання продуктивність.

Причина цього проста: люди, які прагнуть до продуктивності до чистоти та елегантності, майже завжди закінчують останніми. Їх код стає нечистотою, тому що вони відмовились від усього доброго, щоб насправді нічого з цього не отримати.

Написавши спочатку хороший, читабельний код, більшість з вас проблеми з продуктивністю вирішать самі. І якщо пізніше ви виявите, що вашої продуктивності не вистачає, тепер легко додати профайлер до вашого приємного, чистого коду і з’ясувати, де проблема.

Все сказане - std::queueце лише адаптер. Він забезпечує безпечний інтерфейс, але використовує інший контейнер всередині. Ви можете вибрати цей основний контейнер, і це забезпечує значну гнучкість.

Отже, який базовий контейнер слід використовувати? Ми знаємо , що std::listі std::dequeяк забезпечити необхідні функції ( push_back(), pop_front()і front()), так як ми вирішили?

По-перше, зрозумійте, що виділення (і вивільнення) пам’яті, як правило, не є швидким завданням, оскільки воно передбачає вихід до ОС та прохання її щось зробити. A listповинен виділяти пам'ять кожного разу, коли щось додається, і звільняти її, коли вона зникає.

А deque, з іншого боку, розподіляє шматками. Він буде виділяти рідше, ніж a list. Подумайте про це як про список, але кожен фрагмент пам’яті може містити кілька вузлів. (Звичайно, я б запропонував вам справді дізнатися, як це працює .)

Отже, лише з цим a dequeповинен працювати ефективніше, оскільки він не так часто справляється з пам’яттю. У поєднанні з тим, що ви обробляєте дані постійного розміру, їм, ймовірно, не доведеться розподіляти їх після першого проходження через дані, тоді як список буде постійно розподіляти та звільняти.

Друге, що слід зрозуміти - це продуктивність кешу . Вихід до оперативної пам’яті відбувається повільно, тому, коли процесору справді потрібно, він робить все можливе, забираючи частину пам’яті назад у кеш. Оскільки dequeрозподіл у фрагментах пам'яті, цілком ймовірно, що доступ до елемента в цьому контейнері призведе до того, що процесор поверне назад і решту контейнера. Тепер будь-який подальший доступ до dequeбуде швидким, оскільки дані знаходяться в кеші.

Це на відміну від списку, де дані розподіляються по одному. Це означає, що дані можуть поширюватися повсюдно в пам'яті, і продуктивність кешу буде поганою.

Отже, зважаючи на це, dequeкращим вибором має бути a. Ось чому це контейнер за замовчуванням при використанні queue. З усього сказаного, це все ще лише (дуже) освічена здогадка: вам доведеться профілювати цей код, використовуючи dequeв одному тесті, а listв іншому, щоб насправді точно знати.

Але пам’ятайте: змушуйте код працювати з чистим інтерфейсом, тоді турбуйтеся про продуктивність.

Джон висловлює занепокоєння тим, що обгортання listабо dequeспричинить зниження продуктивності. Ще раз, ні він, ні я не можемо сказати напевно, не профілюючи це самі, але, швидше за все, компілятор вбудує дзвінки, які queueробить. Тобто, коли ви говорите queue.push(), це справді просто скаже queue.container.push_back(), повністю пропускаючи виклик функції.

Ще раз, це лише освічена здогадка, але використання queueволі не погіршить продуктивність у порівнянні з використанням базового контейнера raw. Як я вже говорив раніше, використовуйте queue, оскільки він чистий, простий у використанні та безпечний, і якщо він справді стає проблемним профілем та тестом.

Перевірте std::queue. Він обгортає базовий тип контейнера, а контейнером за замовчуванням є std::deque.

Там, де продуктивність дійсно важлива, перегляньте бібліотеку кругового буфера Boost .

Я постійно створюю push_backнові елементи, pop_frontпереглядаючи найстаріший елемент (близько мільйона разів).

Мільйон - це насправді не велика цифра в обчислювальній техніці. Як пропонували інші, використовуйте a std::queueяк перше рішення. Навряд чи це буде занадто повільно, визначте вузьке місце за допомогою профілювача (не вгадуйте!) Та повторно реалізуйте, використовуючи інший контейнер з однаковим інтерфейсом.

Чому ні std::queue? Все, що у нього є, це push_backі pop_front.

Черга , ймовірно , більш простий інтерфейс , ніж дека , але для такого невеликого списку, різниця в продуктивності, ймовірно , незначна.

Те саме стосується і списку . Це просто вибір того, який API ви хочете.

Використовуйте a std::queue, але пам’ятайте про компроміси щодо ефективності двох стандартних Containerкласів.

За замовчуванням std::queueє адаптером поверх std::deque. Як правило, це дасть хорошу продуктивність, якщо у вас невелика кількість черг, що містять велику кількість записів, що, мабуть, є загальним випадком.

Однак не будьте сліпими до реалізації std :: deque . Зокрема:

"... деки зазвичай мають великі мінімальні витрати на пам'ять; дек, що містить лише один елемент, повинен розподілити свій повний внутрішній масив (наприклад, у 8 разів більший за розмір об'єкта в 64-розрядному libstdc ++; у 16 ​​разів більше об'єкта або 4096 байт, залежно від того, що більше , на 64-розрядному libc ++). "

Щоб це визначити, припускаючи, що запис черги - це те, що ви хочете поставити в чергу, тобто досить невеликий за розміром, тоді, якщо у вас є 4 черги, кожна з яких містить 30000 записів, std::dequeреалізація буде варіантом вибору. І навпаки, якщо у вас 30000 черг, кожна з яких містить 4 записи, то, швидше за все, std::listреалізація буде оптимальною, оскільки ви ніколи не амортизуєте std::dequeнакладні витрати в цьому сценарії.

Ви прочитаєте багато думок про те, як кеш кеш, як Страуструп ненавидить пов'язані списки тощо, і все це правда, за певних умов. Просто не приймайте це на сліпій вірі, тому що в нашому другому сценарії там, навряд чи std::dequeбуде виконано стандартне виконання. Оцініть ваше використання та вимірювання.

Цей випадок досить простий, і ви можете просто написати свій власний. Ось щось, що добре працює для ситуацій мікроконтролера, коли використання STL займає занадто багато місця. Це гарний спосіб передавати дані та сигнал від обробника переривань до вашого основного циклу.

// 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);}
};