Коли ви розподіляєте пам'ять у купі, єдиним обмеженням є вільна оперативна пам'ять (або віртуальна пам'ять). Це робить Gb пам'яті.
То чому розмір стека настільки обмежений (близько 1 Мб)? Яка технічна причина заважає вам створювати по-справжньому великі об’єкти в стеку?
Оновлення : Мої наміри можуть бути незрозумілими, я не хочу розподіляти величезні об’єкти в стеку, і більший стек мені не потрібен . Це питання - лише чиста цікавість.
Відповіді:
Моя інтуїція полягає в наступному. Керувати стеком не так просто, як купою. Стек потрібно зберігати в постійних місцях пам'яті. Це означає, що ви не можете випадковим чином розподілити стек за необхідністю, але для цього вам потрібно принаймні зарезервувати віртуальні адреси. Чим більше розмір зарезервованого віртуального адресного простору, тим менше потоків ви можете створити.
Наприклад, 32-розрядна програма, як правило, має віртуальний адресний простір 2 Гб. Це означає, що якщо розмір стека становить 2 МБ (за замовчуванням у pthreads), ви можете створити максимум 1024 потоки. Це може бути невеликим для таких програм, як веб-сервери. Збільшення розміру стека, скажімо, до 100 МБ (тобто, ви зарезервуєте 100 МБ, але не обов’язково відразу ж виділите 100 МБ для стека), обмежило б кількість потоків приблизно до 20, що може бути обмеженням навіть для простих графічних програм.
Цікавим питанням є те, чому ми досі маємо цей ліміт на 64-розрядні платформи. Я не знаю відповіді, але я припускаю, що люди вже звикли до деяких "найкращих практик стеку": будьте обережні, щоб розподілити величезні об'єкти в купі і, якщо потрібно, збільшити розмір стека вручну. Тому ніхто не знайшов корисним додавати "величезну" підтримку стека на 64-розрядні платформи.
Один аспект, про який ще ніхто не згадував:
Обмежений розмір стека - це механізм виявлення помилок та стримування.
Як правило, основною роботою стека в C і C ++ є відстеження стека викликів та локальних змінних, і якщо стек росте поза межами, це майже завжди є помилкою в дизайні та / або поведінці програми .
Якщо стеку дозволити довільно збільшуватися, ці помилки (як нескінченна рекурсія) будуть вловлюватися дуже пізно, лише після того, як ресурси операційної системи будуть вичерпані. Цьому запобігає встановлення довільного обмеження розміру стека. Фактичний розмір не настільки важливий, крім того, що він досить малий, щоб запобігти погіршенню системи.
std::unique_ptrдля написання деструктора (і не покладаючись на розумний вказівник)).
Це просто розмір за замовчуванням. Якщо вам потрібно більше, ви можете отримати більше - найчастіше, кажучи лінкеру виділити додатковий простір стека.
Недоліком великих стеків є те, що якщо ви створюєте багато ниток, їм знадобиться по одному стеку. Якщо всі стеки виділяють кілька МБ, але не використовують його, простір буде витрачено даремно.
Ви повинні знайти належний баланс для вашої програми.
Деякі люди, як @BJovke, вважають, що віртуальна пам'ять по суті безкоштовна. Це правда, що вам не потрібно мати фізичну пам’ять, яка підтримує всю віртуальну пам’ять. Ви повинні мати можливість принаймні видавати адреси у віртуальну пам’ять.
Однак на типовому 32-розрядному ПК розмір віртуальної пам'яті збігається з розміром фізичної пам'яті - оскільки ми маємо лише 32 біти для будь-якої адреси, віртуальної чи ні.
Оскільки всі потоки в процесі мають однаковий адресний простір, вони повинні розділити його між собою. А після того, як операційна система взяла свою участь, для програми залишається "лише" 2-3 ГБ. І цей розмір є обмеженням як для фізичної, так і для віртуальної пам’яті, оскільки адрес просто більше немає.
З одного боку, стек є безперервним, тому, якщо ви виділяєте 12 МБ, ви повинні видалити 12 МБ, коли ви хочете опуститися нижче того, що ви створили. Також переміщення предметів навколо стає набагато складнішим. Ось приклад із реального світу, який може полегшити розуміння:
Скажімо, ви складаєте коробки по кімнаті. Що простіше в управлінні:
Ці два приклади є грубими узагальненнями, і є деякі моменти, які явно помиляються в аналогії, але це досить близько, що, сподіваємось, допоможе вам побачити переваги в обох випадках.
Подумайте про стек у порядку, близькому до далекого. Регістри близькі до центрального процесора (швидко), стек трохи далі (але все ще відносно близько) і купа далеко (повільний доступ).
Стек живе на купі курсу, але все ж, оскільки він використовується постійно, він, ймовірно, ніколи не залишає кеш (и) центрального процесора, що робить його швидшим, ніж просто середній доступ до купи. Це є причиною зберігати стек розумних розмірів; щоб максимально зберегти його в кешу. Виділення великих об’єктів стека (можливо, автоматичне змінення розміру стека в міру переповнення) суперечить цьому принципу.
Отже, це хороша парадигма для продуктивності, а не просто залишки старих часів.
Багато речей, для яких, на вашу думку, вам потрібен великий стек, можна зробити іншим способом.
"Алгоритми" Седжвіка має кілька хороших прикладів "видалення" рекурсії з таких рекурсивних алгоритмів, як QuickSort, шляхом заміни рекурсії на ітерацію. Насправді алгоритм все ще рекурсивний, і він все ще існує як стек, але ви виділяєте стек сортування в купі, а не використовуючи стек часу виконання.
(Я віддаю перевагу другому виданню з алгоритмами, поданими на мові Паскаль. Його можна використовувати за вісім доларів.)
Ще один спосіб подивитися на це - якщо ви вважаєте, що вам потрібен великий стек, ваш код неефективний. Існує кращий спосіб, який використовує менше стека.
Я не думаю, що існує якась технічна причина, але це був би дивний додаток, який щойно створив лише один величезний супер-об'єкт у стеку. Об'єктам стеку не вистачає гнучкості, що стає більш проблематичним із збільшенням розміру - ви не можете повернутися, не знищивши їх, і ви не можете поставити їх у чергу в інші потоки.
int main() { char buffer[1048576]; } Це дуже поширена проблема для початківців. Звичайно, існує простий спосіб вирішення проблеми, але чому нам слід обходити розмір стека?