Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> Начинающий программист, gcc и стек
NotLiquid
сообщение 13.10.2009 - 17:14
в вечном поиске
*******

Группа: Участник
Сообщений: 8163
Регистрация: 24.11.2007
Пользователь №: 21977


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

unsigned int array[0x400000];

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

Вопрос. Сей немалый массив где будет находиться? Неужто в стеке? И адресация к нему будет производиться по stack pointer?
Перейти в начало страницы
 
+Цитировать сообщение
leah
сообщение 13.10.2009 - 17:52
Постоялец форума
*****

Группа: Модератор
Сообщений: 967
Регистрация: 17.08.2004
Пользователь №: 4400


Цитата(NewJesus @ 13.10.2009 - 18:14) *
Есть у нас такое объявление:

unsigned int array[0x400000];

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

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

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

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

А вообще-то обычно не в таких местах происходит деградация производительности (IMG:http://forum.netall.ru/style_emoticons/default/sad.gif) Хотя я бы такой код завернул куда подальше по нескольким причинам: нерасширяем, потенциально уязвим, просто плохой стиль программирования, непонятно к чему сей массив относится...

Сообщение отредактировано leah - 13.10.2009 - 17:53
Перейти в начало страницы
 
+Цитировать сообщение
Roman Ivanov
сообщение 16.06.2010 - 16:20
Новичок
*

Группа: Участник
Сообщений: 4
Регистрация: 16.06.2010
Пользователь №: 30694


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

это почему же так? Они же выделяют память в куче, и в общем случае, это медленнее чем при выделении памяти в стеке.
Перейти в начало страницы
 
+Цитировать сообщение
leah
сообщение 16.06.2010 - 21:49
Постоялец форума
*****

Группа: Модератор
Сообщений: 967
Регистрация: 17.08.2004
Пользователь №: 4400


Цитата(Roman Ivanov @ 16.06.2010 - 17:20) *
это почему же так? Они же выделяют память в куче, и в общем случае, это медленнее чем при выделении памяти в стеке.

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

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

Надеюсь убедил, что большие объемы лучше аллокировать...
Перейти в начало страницы
 
+Цитировать сообщение
Roman Ivanov
сообщение 18.06.2010 - 09:29
Новичок
*

Группа: Участник
Сообщений: 4
Регистрация: 16.06.2010
Пользователь №: 30694


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

p.s. Единственное, что интересно, зачем в gcc разрешили динамически выделять на стеке массивы. %)
Перейти в начало страницы
 
+Цитировать сообщение
leah
сообщение 21.06.2010 - 16:16
Постоялец форума
*****

Группа: Модератор
Сообщений: 967
Регистрация: 17.08.2004
Пользователь №: 4400


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

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

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

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

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

Ответить в данную темуНачать новую тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 



RSS Текстовая версия Сейчас: 25.05.2020 - 08:10