Начинающий программист, gcc и стек Опции

[NotLiquid]

Есть у нас такое объявление:

unsigned int array[0x400000];

Есть у нас среда разработки, использующая gcc, и компилящая этот код.

Вопрос. Сей немалый массив где будет находиться? Неужто в стеке? И адресация к нему будет производиться по stack pointer?

[leah]

Есть у нас такое объявление:

unsigned int array[0x400000];

Есть у нас среда разработки, использующая gcc, и компилящая этот код.

Вопрос. Сей немалый массив где будет находиться? Неужто в стеке? И адресация к нему будет производиться по stack pointer?

А это смотря где его объявить... если в теле функции, то таки да - в стеке. Если глобальным, то в data -сегменте (по идее...)
А что так смущает, если по stack-pointer? Это же регистр и операция к нему со смещением, тем более, что компиляторы уже давно достаточно умные и пытаются оптимизировать всякие разные обращения через использование дополнительных регистров. Т.е. в тривиальном случае может получиться и так, что адрес просто запишется в какой нибудь регистр, но это нужно смотреть что конкретно нагенерил компилятор путем вывода в ассемблер...

По хорошему, нужно конечно malloc/free использовать (или их аналоги).

А вообще-то обычно не в таких местах происходит деградация производительности Хотя я бы такой код завернул куда подальше по нескольким причинам: нерасширяем, потенциально уязвим, просто плохой стиль программирования, непонятно к чему сей массив относится...

Сообщение отредактировано leah - 13.10.2009 - 17:53

[Roman Ivanov]

По хорошему, нужно конечно malloc/free использовать (или их аналоги).

это почему же так? Они же выделяют память в куче, и в общем случае, это медленнее чем при выделении памяти в стеке.

[leah]

это почему же так? Они же выделяют память в куче, и в общем случае, это медленнее чем при выделении памяти в стеке.

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

А вот почему именно так (все конечно же сильно зависит от реализации конкретной библиотеки и операционной системы):
1) malloc и аналоги выделяют память не в куче, а берут ее у системы, соответственно нам будет доступна не только память в размере стека (см. п. 3), а вся память размеченная в системе.
2) malloc возвращает код ошибки и если что не так, то не приводит к краху программы, процесса, потока (нужное подчеркнуть).
3) вот стек как раз не бесконечен увы и обычно равен размерности архитектуры процессора (8,16,32,64,128 бит), в отличии от количества памяти в самой системе.
4) если система умная, то она еще и память будет расходовать только внутри занятых страниц! (например линукс), т.е. если обращения к странице системной памяти не было, то она у системы и не отберется, фактически получается выделение по запросу - ничего не пытались записать, ничего и не дали!
5) не дай Бог выделить память в функции на стеке и вернуть на нее указатель! (последствия понятны надеюсь...)
6) память нужно выделять когда она действительно необходима, а не на "про запас", касается глобальных - если памяти в системе мало, то программа просто не запустится и не будет возможности сказать пользователю сколько нужно этой памяти добавить для сакцеса!
7) ну уж если совсем приперло выделить память такого объема на стеке, то используйте alloca/malloca/аналоги
проще найти все вызовы *alloc*/free* в коде программы, чем долго профилировать в отладчике!

Надеюсь убедил, что большие объемы лучше аллокировать...

[Roman Ivanov]

Я использую такой подход:
1) если я знаю сколько конкретно байт и под какие данные нужно, и если это не мегабайты, конечно, я выделяю память в стеке.
2) если размер будет известен только во время выполнение, и он не будет огромным, я использую malloc()
3) если размеры требуемые под данные исчисляются сотнями мегабайт, то используем СУБД встраиваемую или нет, не важно.

p.s. Единственное, что интересно, зачем в gcc разрешили динамически выделять на стеке массивы. %)

[leah]

Я использую такой подход:
1) если я знаю сколько конкретно байт и под какие данные нужно, и если это не мегабайты, конечно, я выделяю память в стеке.
2) если размер будет известен только во время выполнение, и он не будет огромным, я использую malloc()
3) если размеры требуемые под данные исчисляются сотнями мегабайт, то используем СУБД встраиваемую или нет, не важно.

p.s. Единственное, что интересно, зачем в gcc разрешили динамически выделять на стеке массивы. %)

С первыми двумя пунктами согласен и на мой взгляд это правильно.

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

Что же касается выделения на стеке, то это не прерогатива GCC, микрософтовский компилятор (точнее библиотека!!!) тоже такое имеет ]]>http://msdn.microsoft.com/en-us/library/5471dc8s.aspx]]> , тем более это приносит свои плоды в некоторых случаях.