Хобрук: Ваш путь к мастерству в программировании

Разница в памяти между фактической из диспетчера задач и ручным расчетом в односвязном списке С++

Я запускаю операцию добавления односвязного списка С++ для 100000000 узлов, каждый раз узел принимает случайное число от 0 до 10. В 64-битном Centos он занимает размер 16 для каждого узла, поэтому он будет 1600000000, но согласно диспетчеру задач отображается как 30,53 МБ для каждого узла.

Класс узла содержит данные int и node* next, вот и все.

Мои вопросы:

1.Почему это другое?

2. Есть ли какой-то конкретный способ получить одинаковый размер?

02.09.2013

  • Звучит странно. Первое, что вам нужно сделать правильно, это правильное измерение ресурсов памяти. 02.09.2013
  • согласно диспетчеру задач, показанному как 30,53 МБ для каждого узла - что это значит? Вы действительно видите, что используется 3053000000000000 байт? Где вы купили компьютер? 02.09.2013

Ответы:


1

Все «куски» выделяемой памяти имеют накладные расходы, которые обычно составляют 16–64 байта на выделение.

Если вы делаете два выделения памяти подряд, как далеко они друг от друга. Например.

char *a = new char;
char *b = new char;

std::cout << b-a << std::endl;

delete a;
delete b;

(И да, прежде чем кто-то еще укажет на это: технически этот код является неопределенным поведением. Но на машине x86-64 память представляет собой плоскую модель памяти, поэтому вычитание одного указателя из другого должно дать вам расстояние между двумя объектами. Одна из причин, по которой стандарт не учитывает «разницу между памятью разных выделений», заключается в том, что архитектура может использовать сегментированную память а-ля 16-битная OS/2, где каждое выделение имеет свой собственный сегмент, и сегмент имеет свой собственный базовый адрес, где базовый адрес не известен приложению пользовательского режима, поэтому такой трюк использовать невозможно)

02.09.2013
  • Да, это обеспечивает 32 ... можете ли вы сказать какой-нибудь точный способ решить мою проблему? 02.09.2013
  • Так что это отвечает на ваш вопрос, не так ли? У вас есть 32 байта накладных расходов на элемент. Таким образом, использование вашей памяти соответствует ожидаемому использованию памяти, если мы используем 32 вместо 16. Или вы на самом деле имели в виду 30,53 МБ для каждого узла, то есть использование вашей памяти находится в диапазоне терабайт? Конечно, вы можете улучшить использование памяти, выделяя ее большими блоками, но это также делает код более сложным. Не использовать связанный список, конечно, было бы еще одним вариантом... 02.09.2013

  • 2

    Как вы создаете узлы для своего списка? new? malloc? Все эти функции выделения памяти потребляют некоторое дополнительное пространство, чтобы обеспечить управление памятью (например, освобождение и освобождение памяти). Эти накладные расходы наиболее очевидны, когда вы выделяете много маленьких фрагментов памяти.

    Я думаю, что это причина этих накладных расходов памяти, которые вы видите.

    Вы можете попробовать следующее:

    • Если вы выделяете только небольшие фрагменты одинакового размера, попробуйте использовать фиксированный массив (или просто массив с однократным выделением), а затем используйте указатели на элементы массива как next элемент вашего узла списка.
    • Вы также можете попробовать альтернативные реализации malloc, например tcmalloc.
    02.09.2013
  • я использовал новый для выделения памяти 02.09.2013
  • На самом деле добавление информации о размере (из malloc) дает: 3000/24 ​​= 125 02.09.2013
  • Новые материалы

    Структуры данных в C ++ - Часть 1
    Реализация общих структур данных в C ++ C ++ - это расширение языка программирования C, которое поддерживает создание классов, поэтому оно известно как C с классами . Он используется для..

    Как я опубликовал свое первое приложение в App Store в 13 лет
    Как все началось Все началось три года назад летом после моего четвертого класса в начальной школе. Для меня, четвертого класса, лето кажется бесконечным, пока оно не закончится, и мой отец..

    Что в лицо
    Очерк о возвращении физиогномики и о том, почему мы должны это приветствовать. История начинается со странной науки. Р. Тора Бьорнсдоттир, Николас О. Рул. Видимость социального класса по..

    Почему шаблоны проектирования и почему нет?
    Сложность — мать всех проблем в программировании. Программное обеспечение должно быть разработано с точки зрения того, кто его поддерживает, а не того, кто его пишет, потому что программное..

    Создание дизайна обуви с помощью машинного обучения
    Обувь. Что подождать? Я думал, что речь пойдет о машинном обучении! Ну это так. Если бы вы пошли на Amazon, сколько обуви вы бы нашли? Наверное, много, не так ли? Но много ли в них..

    GraalVM в 2022 году: итоги года
    2022 год был очень продуктивным для проекта и сообщества GraalVM. Вместе мы разработали множество новых функций, выпустили GraalVM для последних версий Java и новых платформ и увидели несколько..

    Быстрая разработка: волшебный мир больших языковых моделей
    РУКОВОДСТВО Быстрая разработка: волшебный мир больших языковых моделей Подход, основанный на данных, для получения наилучшего ответа Искусство и наука Можно ли совместить машинное..