Какое количество оперативной памяти в байтах занимает данный массив
Обновлено: 06.07.2024
то сколько выделится памяти под массив? Зависит от компилятора?
Я предполагаю, что выделится ровно столько, сколько элементов перечислено в списке (т. е. sizeof(тип) * количество элементов в списке).
Я предполагаю, что выделится ровно столько, сколько элементов перечислено в списке
Совершенно верно за одним исключением. Памяти может выделятся чуть больше из-за выравнивания. Доступ к памяти по выровненным адресам намного быстрее происходит, из-за чего эффективнее например выделить дополнительный байт в начале (что бы адрес массива стал кратным 2/4/8/16 (смотря какое выравнивание в архитектуре используется). а можно ли как-то узнать, сколько байтов выделяется дополнительно?
dableproger: возможно попробовать перед массивом объявить переменную и вычислить разность адреса массива и адреса переменной и ещё отнять размер переменной. Получите размер неиспользуемого места перед массивом.
Вот только я не уверен, гарантирует ли компилятор определённый порядок переменных. В структурах гарантирует точно.
fshp: гарантирует. В обеих случаях. И на стеке и на куче.
Вот только в случае со стеком - они будут в обратном порядке. Стек растет в сторону уменьшения адресов, то есть более "поздняя" переменная выделится в стеке "выше", т.е по адресам она будет раньше.
Связано это с тем, что локальные переменные на стеке выделяются через вычитание требуемой памяти из указателя на вершину стека, и добавление инициализированных переменных через push до этого, которая кладет их "сверху" стека.
SolidMinus: на куче точно не гарантирует, т.к. память может быть фрагментирована. И если первое выделение не помещается в первый фрагмент, а второе помещается - то адреса будут в обратном порядке.
А со стеком верное замечание, да.
Пытаться гадать о внутреннем строении компилятора по адресам локальных переменных менее эффективно, чем делать то же на кофейной гуще.
MiiNiPaa: переменные на которые есть reference в коде удалить он не может, он может их оптимизировать в использование регистрами, в примере он их удалил потому что дабл нигде не используется, але)))
Но если в коде будет оператор & перед именем переменной - в регистр он ее не запихнет, т.к у регистров нет адреса в памяти.
Изменение порядка такое связано с тем, что double занимает памяти больше чем int, поэтому сначала пушится инт, потом дабл. Имелось ввиду переменные одного типа.
Ты лучше не адреса выводи через принтф, а дизассемблируй мейн функцию и смотри как что меняется там.
· Описание массивов и обращение к ним на языке Pascal.
· Ввод и вывод элементов массива.
Массив – это величина регулярного типа. Регулярный тип данных – это структурный тип данных, который используется для хранения пронумерованных величин одного типа. Это означает, что массив состоит из ячеек оперативной памяти, в которых хранятся данные одного типа. Эти ячейки называются элементами массива. Они расположены в оперативной памяти компьютера последовательно и каждая из них имеет порядковый номер, который называется индексом элемента массива.
На языке Pascal массивы описываются в блоке описания используемых данных. Например, в разделах описания констант и переменных. Рассмотрим описание массива в разделе описания переменных. Сначала, как у любой переменной, у массива указывается имя или идентификатор дальше после двоеточия, через пробел, записывается служебное слово array, что в переводе с английского языка означает «массив». После него, через пробел, в квадратных, или иначе индексных, скобках указывается тип индексов элементов массива. После квадратных скобок, через пробел, следует служебное слово of, после которого, через пробел, указывается тип элементов массива.
<имя>: array [<тип индексов>] of <тип элементов>;
Чаще всего в качестве типа индексов указывается ограниченный тип, который представляет собой набор значений в указанном диапазоне. Диапазон указывается следующим образом:
[<Начальное значение>..<Конечное значение>]
Описание ограниченного типа
В качестве примера зададим массив, который будет хранить количество яблок в каждой из восьми корзин. Назовём массив k. Очевидно, что индексами элементов массива будут номера корзин – целые числа от 1 до 8. Поэтому в квадратных скобках укажем число 1, через две точки, после которого будет следовать число 8. Дальше запишем служебное слово of. После него укажем тип элементов массива. Пока мы не знаем количества яблок в корзинах, но очевидно, что это будут целые неотрицательные числа и мы предположим, что в одной корзине будет находиться не больше 255 яблок. Поэтому в качестве типа элементов массива укажем тип byte.
k: array [1..8] of byte;
Описание массива для хранения количества яблок в корзинах
При описании массивов важно понимать, что они занимают некоторый объём оперативной памяти, который в некоторых случаях может быть достаточно большим. Например, описанный нами массив для хранения количества яблок содержит 8 элементов типа byte. Переменные этого типа занимают объём оперативной памяти равный одному байту. Таким образом, нам нужно указанный объём оперативной памяти умножить на количество элементов массива.
1 байт × 8 элементов = 8 байт
Так мы вычислили, что заданный нами массив занимает 8 байт оперативной памяти. Рассмотрим ещё один массив, который содержит элементы с порядковыми номерами с 77 по 1100, принадлежащие к целочисленному типу integer. Количество элементов массива 1100 – 77 + 1 = 1024. Так наш массив содержит 1024 элемента. Одна переменная типа inetger в среде Pascal ABC занимает 4 байта оперативной памяти.
4 байта × 1024 элемента = 4096 байт = 4 Кб
Умножив этот объём на количество элементов, мы получим что данный массив будет занимать 4096 байт или 4 килобайта оперативной памяти.
Рассмотрим, как же можно обратиться к элементам массива из программы. Для этого указывается имя, или идентификатор массива, после которого, в квадратных скобках, указывается индекс одного из его элементов. Так, для того, чтобы узнать сколько яблок находится в пятой корзине, мы должны обратиться к элементу массива k с индексом 5 – k[5].
В качестве типа индексов элементов массива в среде Pascal ABC могут использоваться любые перечисляемые типы размерностью до 2 байт включительно. Например мы можем задать символьный или логический тип индексов массива. Индексами элементов таких массивов будут соответственно значения символьного или логического типа. Тип элементов массива не ограничен.
Часто при написании программы необходимое количество элементов в массиве неизвестно заранее, так как задаётся пользователем. При этом изменение количества элементов массива в теле программы невозможно. Поэтому при описании количество элементов массива задаётся максимально возможным по условию задачи, а при работе программы используется необходимая часть элементов массива в соответствии с данными, введёнными пользователем.
for i:=1 to n do
Цикл ввода элементов массива
for i:=1 to n do
Теперь рассмотрим, как организовать вывод массива. Вывод массивов также осуществляется поэлементно. Наиболее часто требуется вывести значения элементов массива в одну строку. Для этого достаточно написать такой же цикл с параметром, как и при вводе, только в нём будет следовать оператор write, выводящий на экран значение элемента массива с индексом i. Но так элементы массива будут выведены в одну строку без разделителей. Поэтому в этот же оператор вывода нужно добавить вывод некоторого разделителя после элемента массива, например, символа пробел.
for i:=1 to n do
Цикл вывода элементов массива
До этого мы рассматривали одномерные массивы. Однако в языке Паскаль можно использовать многомерные массивы. Начнём с двумерных. Наглядно такие массивы можно представить в виде таблицы значений, состоящей из строк и столбцов. Пример такого массива – таблица Пифагора. Двумерные массивы в языке Паскаль трактуются как массивы массивов. Пусть у нас есть 5 полок, на которых располагается по 8 корзин с яблоками. То есть, для описания количества яблок в корзинах нам нужен массив из 5 элементов. Элементами которого будут массивы из 8 элементов типа byte. Опишем такой массив. Назовём его t. После двоеточия будет следовать служебное слово array, после которого в квадратных скобках укажем тип индексов массива – целые числа от 1 до 5, по числу полок. После служебного слова of, укажем тип элементов массива. Это будут массивы, то есть укажем служебное слово array. В квадратных скобках укажем тип индексов 5 массивов, то есть целые числа от 1 до 8. Элементами этих массивов будут числа типа byte.
t: array [1..5] of array [1..8] of byte;
Описание массива массивов
Если двумерный массив описан таким образом, то при обращении к его элементам необходимо в первых квадратных скобках указывать номер массива – целое число от 1 до 5, а во вторых квадратных скобках – номер элемента в этом массиве – число от 1 до 8.
t[a][b], где 1 ≤ a ≤ 5, 1 ≤ b ≤ 8
Обращение к элементу описанного массива
Но возможна и более короткая форма описания массива, при этом в квадратных скобках указывается тип индексов первого массива, в нашем случае целые числа в диапазоне от 1 до 5, после него через запятую указывается тип индексов массивов, из которых он состоит, то есть целые числа в промежутке от 1 до 8. После квадратных скобок следует слово of, после него указывается тип элементов из которых состоят внутренние массивы, то есть byte.
t: array [1..5, 1..8] of byte;
Описание двумерного массива
Индекс элемента такого массива будет состоять из двух целых чисел, указанных через запятую. Первое из них будет в диапазоне от 1 до 5, а второе – от 1 до 8. Аналогично можно описывать массивы и с большим числом измерений, например, трёхмерные и четырёхмерные.
for i:=1 to n do
for j:=1 to m do
Цикл ввода элементов двумерного массива
Вывод элементов двумерного массива будет организован также с помощью вложенного цикла, однако вложенный цикл будет находиться в логических скобках и будет содержать оператор вывода элемента массива t[i, j]. После вложенного цикла во внешнем цикле будет следовать оператор writeln без параметров. Таким образом, мы получим построчный вывод элементов двумерного массива. Но так как значения элементов массива могут быть числами различной длины, стоит указать формат их вывода. Например, выделим для вывода каждого числа по 4 знаковых позиции. Тогда при выводе мы получим ровные столбцы из чисел.
for i:=1 to n do
for j:=1 to m do
Цикл вывода элементов двумерного массива
Помимо поэлементных действий над массивами, есть два случая, когда к массивам можно обращаться как к единому целому. Мы можем присвоить элементам одного массива значения элементов другого массива. Также мы можем проверить равенство и неравенство элементов одного массива элементам другого массива. В обоих случаях случаях у массивов должны совпадать типы индексов и типы элементов.
Важно запомнить:
· Массивы – это переменные, которые используются для хранения пронумерованных величин одного типа.
· Порядковый номер элемента массива называется индексом.
· Большинство операций над массивами, в том числе их ввод и вывод производятся поэлементно.
· Над массивами как над единым целым возможны 3 действия: присваивание, а также проверка их равенства и неравенства.
Тест состоит из 5 вопросов. На прохождение теста у Вас есть 1 попытка, последующие результаты учитываться не будут!
long unsigned int = 4 байта.
1024 * 1024 * long unsigned int = 4 мегабайта.
Почему же массив, наполненный числами от 0 до 1024 * 1024 занимает в памяти 40 мегабайт? (в php еще в два раза больше). Я понимаю, у каждого элемента есть там индекс, указатели какие-то, но хочу не понимать, а четко знать, куда моя память тратится?
По просьбе трудящихся прикладываю код:
По просьбе трудящихся прикладываю скрины:
Ubuntu (как это интерпретировать я хз, но кому интересно вот):
P.S. Из чего вообще возник этот вопрос - у меня есть около 3кк ip адресов, которым надо в соответствие поставить 3кк неких id. Но на это уходит почти гигабайт этой самой памяти (два массива по три миллиона чисел или объект с ключом-значением, разница небольшая), тогда как csv-файлик со двумя столбцами этих чисел весит всего 30мб.
13k 2 2 золотых знака 20 20 серебряных знаков 55 55 бронзовых знаков Хотите четко знать - посмотрите исходники движков js и php. Организация памяти из внутреннее дело и может меняться от версии к версии конкретного продукта. Если даже сейчас это посмотреть и написать тут ответ, то завтра ситуация может в корне изменится Комментарии не предназначены для расширенной дискуссии; разговор перемещен в чат.Для начала, не стоит в языках со сборкой мусора пытаться что-либо связанное с внутренним устройством памяти замерить снаружи. RSS - объем ОП, который занимает сам процесс ноды, с тем, сколько реально "занято", а сколько "прозапас" коррелирует слабо.
В частности, нода, очень любит кушать память. Пока система дает ей оперативную память, она будет ее запрашивать, если происходит много аллокаций. Сделано это прежде всего для скорости работы.
Как верно заметил Artur Udod в комментарии, в javascript, согласно стандарту, все числа - 64х битовые, т.е. 8 байт на число.
Чтобы замерить правильно размер 1 элемента массива - необходимо снимать хипдамп, искать там нужный объект и смотреть, а сколько же реально места там занято.
Есть вариант грубого замера. Для этого - запускаем node --expose-gc . Данный флаг позволяет принудительно инициировать отчистку мусора.
Посредством нехитрых вычислений вида:
Получим примерный размер элемента массива в памяти. Тут следует учитывать, что будет погрешность в большую сторону, т.к. REPL на разбор запросов тоже будет кушать память. Причем из той же кучи.
Замерил хип дампом, через аллокацию массива с 100к элементов:
Здесь - 8,53 байта на элемент массива. Однако, стоит помнить, что сам массив тоже занимает память.
В целом, Mike верно подметил, внутреннее устройство, действительно сильно зависит от версии движка, с этим ничего не поделаешь.
Еще один забавный момент заключается в том, что внутреннее устройство массива в V8 сильно зависит от его размера и структуры. К примеру в node версии 5.7.1 массив на 810 312 элементов "весит" значительно больше (примерно 12 байт на элемент), чем на 810 311 элементов (8,004 байта), это уже привет внутреннему устройству движка, вполне возможно, что он просто превращает массив в словарь, тут уже гадать не буду, однако с дальнейшим ростом, "размер" элемента массива опять падает.
long unsigned int = 4 байта.
1024 * 1024 * long unsigned int = 4 мегабайта.
Почему же массив, наполненный числами от 0 до 1024 * 1024 занимает в памяти 40 мегабайт? (в php еще в два раза больше). Я понимаю, у каждого элемента есть там индекс, указатели какие-то, но хочу не понимать, а четко знать, куда моя память тратится?
По просьбе трудящихся прикладываю код:
По просьбе трудящихся прикладываю скрины:
Ubuntu (как это интерпретировать я хз, но кому интересно вот):
P.S. Из чего вообще возник этот вопрос - у меня есть около 3кк ip адресов, которым надо в соответствие поставить 3кк неких id. Но на это уходит почти гигабайт этой самой памяти (два массива по три миллиона чисел или объект с ключом-значением, разница небольшая), тогда как csv-файлик со двумя столбцами этих чисел весит всего 30мб.
13k 2 2 золотых знака 20 20 серебряных знаков 55 55 бронзовых знаков Хотите четко знать - посмотрите исходники движков js и php. Организация памяти из внутреннее дело и может меняться от версии к версии конкретного продукта. Если даже сейчас это посмотреть и написать тут ответ, то завтра ситуация может в корне изменится Комментарии не предназначены для расширенной дискуссии; разговор перемещен в чат.Для начала, не стоит в языках со сборкой мусора пытаться что-либо связанное с внутренним устройством памяти замерить снаружи. RSS - объем ОП, который занимает сам процесс ноды, с тем, сколько реально "занято", а сколько "прозапас" коррелирует слабо.
В частности, нода, очень любит кушать память. Пока система дает ей оперативную память, она будет ее запрашивать, если происходит много аллокаций. Сделано это прежде всего для скорости работы.
Как верно заметил Artur Udod в комментарии, в javascript, согласно стандарту, все числа - 64х битовые, т.е. 8 байт на число.
Чтобы замерить правильно размер 1 элемента массива - необходимо снимать хипдамп, искать там нужный объект и смотреть, а сколько же реально места там занято.
Есть вариант грубого замера. Для этого - запускаем node --expose-gc . Данный флаг позволяет принудительно инициировать отчистку мусора.
Посредством нехитрых вычислений вида:
Получим примерный размер элемента массива в памяти. Тут следует учитывать, что будет погрешность в большую сторону, т.к. REPL на разбор запросов тоже будет кушать память. Причем из той же кучи.
Замерил хип дампом, через аллокацию массива с 100к элементов:
Здесь - 8,53 байта на элемент массива. Однако, стоит помнить, что сам массив тоже занимает память.
В целом, Mike верно подметил, внутреннее устройство, действительно сильно зависит от версии движка, с этим ничего не поделаешь.
Еще один забавный момент заключается в том, что внутреннее устройство массива в V8 сильно зависит от его размера и структуры. К примеру в node версии 5.7.1 массив на 810 312 элементов "весит" значительно больше (примерно 12 байт на элемент), чем на 810 311 элементов (8,004 байта), это уже привет внутреннему устройству движка, вполне возможно, что он просто превращает массив в словарь, тут уже гадать не буду, однако с дальнейшим ростом, "размер" элемента массива опять падает.
Читайте также: