@voipp: Мені не здається, що інформація, яку ви прочитали, відповідає дійсності. Як правильно сказав @DreamChild, і стек, і хіп - не більше ніж апаратура. Те, що стек менше Хіпа за розміром в типовому випадку, не означає нічого: ви можете звертатися до даних локально в хіпі і нелокального в стеці. (Ви мали на увазі кешування на рівні процесора, але воно працює не так, як ви думаєте.) Регістрів в мовах високого рівня немає і не буде ніколи з багатьох причин (наприклад, тому, що оптимізує компілятор вміє оптимізувати краще людини.) - VladD 5 дек '13 о 11:48
- І стек і купа обидва знаходяться фізично в RAM (не розглядаємо архітектурні вивихи з використанням спец. Процесорів / компів)
- Їх розміри і розташування визначаються віссю
- При цьому купа може бути фрагментована (іноді досить сильно). Зазвичай у осей бувають спеціальні процедури для дефрагментації купи.
- Стек зазвичай ніколи не фрагментований (напевно можна придумати реалізації стека з фрагментацією, але це оксюморон).
- Стек як би швидше тому, що у нього єдиний параметр з яким працює - це покажчик положення стека (зазвичай регістр) - тому всі операції зі стеком працюють в рази швидше ніж з купою. Операція вилучення / записи з стека це 1 тілорух процесора POP / PUSH
- З купою складніше саме через його фрагментації і проста операція витягання значення з нього може вилитися в десятки (якщо не сотні) рухів процесора.
- Мінуси стека в малості його розміру (він завжди в порівнянні з купою на порядок менше) - ну і в тому, що доступ до нього тільки послідовний.
відповідь дан 6 дек '13 о 18:47
@Barmaley: 6) Це має сенс для виділення пам'яті в купі, але якщо у вас є вказівник на об'єкт в купі, і покажчик на об'єкт в стеці, швидкість доступу строго однакова. 7) Знову-таки, доступ ведеться не послідовні читанням, а разименованія покажчика. - VladD 6 дек '13 о 20:15
Дійсно, швидкість доступу до даних в стеку і купі однакова. Тобто пункти 5) і 6) це помилка. Я не полінувався і перевірив час заповнення (кілька спроб) масиву з 2 млн. Int (більше в стек у мене не влазить) в купі і стек. void fill (int a [], int n)
@avp треба не так пробувати, треба домогтися того, щоб купа фрагментований - з цією метою треба зробити хмару рандомних аллокации різного розміру і також хаотично їх видаляти, тільки після цього перевірте швидкість доступу до великого (!) масиву в купі. А інакше якщо купа НЕ фрагментована швидкість звичайно буде однаковою. - Barmaley 8 дек '13 о 18:47
Хоч і минуло багато часу з тих пір як ви задали питання, хотілося б відповісти, адже все одно це питання "гугл" і, я думаю, що багато ще відвідають цю сторінку.
Як вам вже відповіли "фізично" - це транзистори і конденсатори. Так що саме питання швидше за все був поставлений не зовсім коректно. Напевно, ви мали на увазі щось на зразок - "Де знаходиться купа і стек, як вони влаштовані".
Також. мабуть. вас цікавить як в цілому влаштована пам'ять, повністю висвітлити це питання у мене не вийде, але я хочу вам показати, вичерпний на мій погляд, матеріал і дати посилання на них. Матеріали російською. Вам потрібно розібратися, що таке віртуальне пам'ять і як вона транслюється в фізичну.
Ось приклад організації сегментной пам'яті.
Це коротко і трохи з приводу подання віртуальної пам'яті в фізичну.
З приводу пристрою пам'яті всередині процесу:
Що зберігається в блоці CODE, а також про багато іншого ви можете дізнатися з Рекомендований мною матеріалів в цій відповіді.
Краще сказати так. Типовими операціями при роботі з пам'яттю є її виділення / звільнення і читання / запис. Операції виділення і звільнення пам'яті працюють в купі повільніше.
Якщо ж ми, наприклад, заводимо покажчик на дані, що лежать в стеці, то різниці в швидкості доступу не буде абсолютно ніякої.
відповідь дан 7 дек '13 в 6:11
"Доступ до даних (читання / запис) відбувається практично з однаковою швидкістю" А якщо дані фрагментовані, то хіба читання їх не сповільниться? - voipp 7 дек '13 об 11:14
@voipp: Що означає «дані фрагментовані»? Якщо ви говорите про фрагментованість масиву, то такого не буває, масив завжди йде підряд. Якщо у ви говорите про звернення до різних об'єктів, вони можуть бути рознесені в пам'яті і при їх розташуванні в стеці, і в купі. - VladD 7 дек '13 о 11:57
Так, підтримую @VladD. Структура теж не може бути фрагментована. Якщо у вас на стеку структура з std :: string, то вміст рядка, зазвичай, - вже в купі :). Швидше треба замислюватися про структурах даних, які варто використовувати, а не про їх розташування. Список, припустимо, іноді може бути краще масиву, але він схильний до фрагментації (і більше пам'яті витрачає). - Михайло М 8 дек '13 в 9:01