почему размер стековой памяти так ограничен?

Моя интуиция следующая. Управлять стеком не так просто, как кучей. Стек необходимо хранить в постоянных ячейках памяти. Это означает, что вы не можете случайным образом распределить стек по мере необходимости, но вам нужно как минимум зарезервировать виртуальные адреса для этой цели. Чем больше размер зарезервированного виртуального адресного пространства, тем меньше потоков вы можете создать.

Например, 32-разрядное приложение обычно имеет виртуальное адресное пространство размером 2 ГБ. Это означает, что если размер стека равен 2 МБ (по умолчанию в pthreads), то вы можете создать максимум 1024 потока. Это может быть мало для таких приложений, как веб-серверы. Увеличение размера стека, скажем, до 100 МБ (т. Е. Вы резервируете 100 МБ, но не обязательно сразу выделяете 100 МБ для стека), это ограничит количество потоков примерно до 20, что может быть ограничением даже для простых приложений с графическим интерфейсом.

Интересный вопрос, почему у нас все еще есть этот лимит на 64-битных платформах. Я не знаю ответа, но предполагаю, что люди уже привыкли к некоторым «лучшим методам работы с стеком»: будьте осторожны, выделяя огромные объекты в куче и, если необходимо, вручную увеличивайте размер стека. Поэтому никому не показалось полезным добавлять поддержку «огромного» стека на 64-битных платформах.

Один аспект, о котором еще никто не упомянул:

Ограниченный размер стека - это механизм обнаружения и устранения ошибок.

Как правило, основная задача стека в C и C ++ заключается в отслеживании стека вызовов и локальных переменных, и если стек выходит за пределы, это почти всегда является ошибкой в ​​дизайне и / или поведении приложения. .

Если стеку позволено увеличиваться до произвольного размера, эти ошибки (например, бесконечная рекурсия) будут обнаружены очень поздно, только после того, как ресурсы операционной системы будут исчерпаны. Это предотвращается установкой произвольного ограничения на размер стека. Фактический размер не так важен, кроме того, что он достаточно мал, чтобы предотвратить деградацию системы.

Это просто размер по умолчанию. Если вам нужно больше, вы можете получить больше - чаще всего, указав компоновщику выделить дополнительное пространство стека.

Обратной стороной больших стеков является то, что если вы создаете много потоков, для каждого из них потребуется по одному стеку. Если все стеки выделяют несколько МБ, но не используют их, пространство будет потрачено впустую.

Вы должны найти правильный баланс для своей программы.

Некоторые люди, например @BJovke, считают, что виртуальная память по сути бесплатна. Это правда, что вам не обязательно иметь физическую память, поддерживающую всю виртуальную память. Вы должны уметь хотя бы выдавать адреса виртуальной памяти.

Однако на типичном 32-битном ПК размер виртуальной памяти такой же, как и размер физической памяти, потому что у нас есть только 32 бита для любого адреса, виртуального или нет.

Поскольку все потоки в процессе используют одно и то же адресное пространство, они должны разделить его между собой. А после того, как операционная система приняла свое участие, для приложения остается "всего" 2-3 ГБ. И этот размер является пределом для как физической , так и виртуальной памяти, потому что просто больше нет адресов.

Во-первых, стек является непрерывным, поэтому, если вы выделяете 12 МБ, вы должны удалить 12 МБ, если хотите опуститься ниже того, что вы создали. Также становится труднее перемещать предметы. Вот пример из реальной жизни, который может упростить понимание:

Допустим, вы складываете коробки по комнате. Чем легче управлять:

• штабелирование коробок любого веса друг на друга, но когда вам нужно что-то достать внизу, вам придется разворачивать всю стопку. Если вы хотите взять предмет из кучи и передать его кому-то другому, вы должны снять все коробки и переместить коробку в кучу другого человека (только для стопки).
• Вы кладете все свои коробки (за исключением действительно маленьких коробок) в специальное место, где вы не складываете вещи поверх других вещей, и записываете, где вы кладете их, на листе бумаги (указатель) и кладете бумагу на куча. Если вам нужно передать коробку кому-то другому, просто дайте ему листок бумаги из вашей стопки или просто дайте им ксерокопию бумаги и оставьте оригинал там, где он был в вашей стопке. (Стек + куча)

Эти два примера являются грубыми обобщениями, и есть некоторые моменты, которые явно неверны в аналогии, но они достаточно близки, чтобы, надеюсь, помочь вам увидеть преимущества в обоих случаях.

Подумайте о стопке в порядке от ближайшего к дальнему. Регистры расположены близко к процессору (быстро), стек немного дальше (но все еще относительно близко), а куча находится далеко (медленный доступ).

Стек, конечно, живет в куче, но все же, поскольку он используется постоянно, он, вероятно, никогда не покидает кеш (ы) ЦП, что делает его быстрее, чем просто средний доступ к куче. Это причина поддерживать размер стека в разумных пределах; чтобы сохранить его в кэше как можно больше. Выделение больших объектов стека (возможно, автоматическое изменение размера стека при переполнении) противоречит этому принципу.

Так что это хорошая парадигма производительности, а не просто пережиток старых времен.

Многие из вещей, для которых, как вы думаете, вам нужен большой стек, можно сделать иным способом.

В «Алгоритмах» Седжвика есть пара хороших примеров «удаления» рекурсии из рекурсивных алгоритмов, таких как QuickSort, путем замены рекурсии на итерацию. На самом деле алгоритм все еще рекурсивный, и все еще есть стек, но вы размещаете стек сортировки в куче, а не используете стек времени выполнения.

(Я предпочитаю второе издание с алгоритмами, приведенными на Паскале. Его можно использовать за восемь долларов.)

Другой способ взглянуть на это: если вы думаете, что вам нужен большой стек, ваш код неэффективен. Есть лучший способ, использующий меньше стека.

Размещение больших объектов в стеке, скажем, 100 МБ сделало бы невозможным на большинстве машин их одновременную загрузку в кеш, что в значительной степени сводит на нет цель стека.

Смысл стека состоит в том, чтобы иметь небольшие объекты, принадлежащие к одной области (и, следовательно, обычно требуемые вместе или близко друг к другу), хранящиеся вместе в смежных адресах памяти, чтобы программа могла загружать их все в кэш по адресу в то же время, сводя к минимуму промахи в кэше и, в общем, время, которое ЦП должен ждать, пока он не получит недостающий фрагмент данных из более медленной ОЗУ.

Объект размером 50 МБ, хранящийся в стеке, не поместится в кеш, что означает, что после каждой строки кеша будет время ожидания ЦП до тех пор, пока из ОЗУ не будет доставлен следующий фрагмент данных, что означает засорение стека вызовов и не получение каких-либо значительных результатов. выгода (по скорости) по сравнению с загрузкой из кучи.

Я не думаю, что есть какая-то техническая причина, но это было бы странное приложение, которое только что создало только один огромный супер-объект в стеке. Объектам стека не хватает гибкости, что становится более проблематичным с увеличением размера - вы не можете вернуться, не уничтожив их, и вы не можете поставить их в очередь в другие потоки.