Навіщо нам потрібна купа, якщо все можна зробити набагато ефективніше на Стек?

Це насправді пов'язане з питанням, яке я задав вчора про те, чому і стек, і купа необхідні в додатках, які ми використовуємо сьогодні (і чому ми не можемо просто перейти з Heap замість обох, щоб мати простий & єдиний стандарт, який потрібно пройти).

Однак багато відповідей вказували на те, що стек є незамінним через те, що в сотні (або тисячі) разів швидше, ніж намагання виділити / посилатись на Кучу. Я знаю, що існує проблема з динамічним розподілом пам’яті, якщо ми скасуємо Купу, але чи не існує способу цього покращити чи, можливо, спосіб покращити стек, щоб він міг обробляти динамічне розподілення пам’яті?

Проблема стеків полягає в тому, що ви не можете "звільнити" пам'ять, якщо вона не знаходиться на вершині стека. Наприклад, скажімо, що ви виділили 3 речі різного розміру:

a = allocate(2000000); // 2000000 bytes
b = allocate(1);
c = allocate(5000000);

Стек був би aзнизу, bпосередині та cзверху. Це стає проблематичним, якщо ми хочемо звільнити b:

free(b); // b is not on top! We have to wait until c is freed!

Вирішення проблеми полягає в переміщенні всіх даних після bта переміщенні, якщо так, щоб вони надходили після a. Це працює, але в цьому випадку знадобиться 5000000 примірників - те, що буде набагато повільніше, ніж купа.

Ось чому ми маємо купу. Хоча розподіл може бути повільнішим, ніж стек ( O(log n)vs O(1)), купи дозволяють звільнити пам'ять у довільному місці швидко - O(log n)порівняно з стекомO(n)

Стек складається за нитку, Купа - це процес

Якщо у вас є 100 ниток, усі робочі елементи, які я обробляю, я поміщаю в чергу, куди я розподіляю такі елементи, щоб хтось із 100 потоків міг їх бачити?

Є й інші типи пам’яті

Напр. Файли, зіставлені з пам'яттю, спільна пам'ять, введення / виведення (карта ядра). Аргумент ефективності є своєрідним суперечкою в цих ситуаціях.

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

Стеки чудово підходять для розподілу пам’яті, що підкоряються правилам Last in First out (LIFO), тобто ви звільняєте пам'ять у точному зворотному порядку, за яким ви її розподіляєте. LIFO - це дуже поширена, можливо, найпоширеніша схема розподілу пам'яті. Але це не єдиний візерунок або навіть єдиний загальний зразок. Щоб скласти ефективну програму, яка може вирішити найрізноманітніші проблеми, ми повинні враховувати менш поширені моделі, навіть якщо це означає більш складну інфраструктуру.

Якщо я можу отримати мета для абзацу: ви початківець, ви як початківець цінуєте простоту та чорно-білі правила. Однак ви, як початківець, маєте лише глибокий погляд на коло проблем та обмежень, які мають бути задоволені комп’ютерними програмами. Ви впроваджуєте технологію, яка вже 75 років активно розвивається. Немає нічого поганого в тому, щоб запитати, чому все так, як вони є, але, як правило, відповідь буде "Так, ми спробували простий, прямолінійний метод 50 років тому, і виявилося, що це не дуже добре працює для цілих класів проблем, тож нам довелося зробити щось складніше ". По мірі прогресу технологій простота, як правило, повинна поступатися місцем ефективності та гнучкості.

Для іншого прикладу, закриття. Якщо ви стек поп, то ви можете втратити запис активації завершення. Тож якщо ви хочете, щоб ця анонімна функція та її дані зберігалися, вам доведеться зберігати її де-небудь, крім стеку виконання.

Серед багатьох інших причин виділення накопичувальних купи.

Якщо ви хочете передати адресу об'єкта назад в програму, що викликає, ви не повинні передавати адресу змінної стека, тому що сховище стека буде повторно використане і, можливо, перезаписане наступною функцією, що викликається. Вам потрібно отримати необхідне сховище за допомогою malloc (), щоб переконатися, що він не буде перезаписаний дзвінками до наступних функцій.

Ви можете передати адреси елементів стеку з вашої функції до функцій, які ви викликаєте, оскільки ви можете гарантувати, що вони існуватимуть, поки ваша програма не повернеться (). Але, як тільки ваша функція повернеться, все сховище стека буде захоплено.