сравнение производительности доступа данных в "куче" и стеке
Это - широко известный здравый смысл, который для большинства алгоритмов, выделяя и освобождая данные по стеку намного быстрее, чем выполнение так на "куче". В C++ различие в коде похоже
double foo[n*n]
по сравнению с.
double* foo = new int[n*n]
Но существуют какие-либо существенные различия, когда дело доходит до доступа и вычисления с данными, которые лежат или на "куче" или на стеке? Т.е. есть ли различие в скорости для
foo[i]
Код, должен работать на нескольких различной архитектуре, поэтому попытаться иметь размеры, не будет работать.
4 ответа
Могут быть (сильно зависящие от системы) проблемы с локализацией кэша и промахами чтения / записи. Если вы запустите свою программу в стеке и данных кучи, то вполне вероятно (в зависимости от архитектуры вашего кеша), что вы столкнетесь с большим количеством промахов в кеше, чем если бы вы запускали ее полностью в одной непрерывной области куча. Вот статья Эндрю Аппеля (из SML / NJ) и Чжун Шао, посвященная этому вопросу, где они исследуют именно это, потому что распределение стека / кучи - это тема для реализации функциональных языков:
http: // citeseerx. ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3778
Они обнаружили некоторые проблемы с производительностью, связанные с пропусками записи, но оценили, что они будут решены за счет достижений в кэшировании.
Я предполагаю, что для современного настольного компьютера / сервера, если вы не используете сильно оптимизированный архитектурно-зависимый код, который передает данные по строкам кэша, вы не заметите никакой разницы между доступом к стеку и кучей. Все может быть иначе для устройств с маленькими кешами (например, ARM / MIPS-контроллер), где игнорирование кеша в любом случае может оказать заметное влияние на производительность.
Взятые как отдельные утверждения, это не имеет значения.
Мало что можно сказать без дополнительного контекста. Есть несколько эффектов в пользу стека, которыми можно пренебречь практически всегда.
стек, скорее всего, уже находится в кэше, а только что выделенный блок кучи, скорее всего, нет. Однако это только штраф за первое исполнение. Для значительных объемов данных вы все равно бы взломали кеш.
Само выделение стека немного дешевле, чем выделение кучи, потому что распределение проще
В долгосрочной перспективе основной проблемой кучи обычно является фрагментация, " «накопленная стоимость», которая (обычно) не может быть отнесена к разовым распределениям, но может значительно увеличить стоимость дальнейших распределений
. Измерение этих эффектов, по крайней мере, непросто.
Рекомендация : производительность здесь не решает. Переносимость и масштабируемость рекомендуют использовать кучу для всех, кроме очень небольшого количества данных.
За исключением выделения, не должно быть заметной разницы между доступом к данным, будь то на основе стека или кучи - это вся память в конце дня.
Стек будет чаще находиться в кэше ЦП , так что в некоторых (большинстве?) Случаев это может быть быстрее.
Но наиболее точный ответ, наверное, таков: это зависит от ...