Почему malloc + memset медленнее, чем calloc?

Question

Почему malloc + memset медленнее, чем calloc?

213

Известно, что calloc отличается от malloc тем, что он инициализирует выделенную память. С calloc память установлена на ноль. С malloc память не очищается.

Поэтому в повседневной работе я рассматриваю calloc как malloc + memset. Кстати, для удовольствия я написал следующий код для теста.

Результат запутан.

Код 1:

#include<stdio.h>
#include<stdlib.h>
#define BLOCK_SIZE 1024*1024*256
int main()
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = (char*)calloc(1,BLOCK_SIZE);
                i++;
        }
}

Вывод кода 1:

time ./a.out  
**real 0m0.287s**  
user 0m0.095s  
sys 0m0.192s

Код 2:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#define BLOCK_SIZE 1024*1024*256
int main()
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = (char*)malloc(BLOCK_SIZE);
                memset(buf[i],'\0',BLOCK_SIZE);
                i++;
        }
}

Вывод кода 2:

time ./a.out   
**real 0m2.693s**  
user 0m0.973s  
sys 0m1.721s

Замена memset на bzero(buf[i],BLOCK_SIZE) в коде 2 дает тот же результат.

Мой вопрос: Почему malloc + memset намного медленнее, чем calloc? Как это сделать calloc?

kingkai 22 апр. 2010, в 05:17

Источник

Теги:

c

malloc

3 ответа

10

Так как во многих системах, в свободное время обработки, ОС обойдется без необходимости устанавливать свободную память в ноль и маркировать ее безопасно для calloc(), поэтому, когда вы вызываете calloc(), у нее может уже быть свободная обнуленная память чтобы дать вам.

Chris Lutz 22 апр. 2010, в 07:04

1

Уверены ли вы? Какие системы это делают? Я думал, что большинство ОС просто выключают процессор, когда они простаивают, и обнуляют память по требованию для процессов, которые выделяются, как только они записывают в эту память (но не когда они выделяют ее).
Dietrich Epp 22 апр. 2010, в 06:00
0

@Dietrich - Не уверен. Я слышал это однажды, и это показалось разумным (и достаточно простым) способом сделать calloc() более эффективным.
Chris Lutz 22 апр. 2010, в 06:06
4

Я думаю, что вы, вероятно, не правы, но я не уверен.
Pierreten 22 апр. 2010, в 06:09
0

@Pierreten - я не могу найти никакой полезной информации о calloc() оптимизациях, и мне не хочется интерпретировать исходный код libc для OP. Можете ли вы найти что-нибудь, чтобы показать, что эта оптимизация не существует / не работает?
Chris Lutz 22 апр. 2010, в 06:13
0

@Chris: код, который вы ищете, находится не в коде libc, а в ядре. Libc просто вызывает sbrk или mmmap и знает, что ядро выдает только обнуленную память из этих двух системных вызовов, поэтому оно не обнуляет эту память снова.
Dietrich Epp 22 апр. 2010, в 06:35
12

@Dietrich: Предполагается, что FreeBSD обнуляет страницы во время простоя: см. Настройку vm.idlezero_enable.
Zan Lynx 07 март 2011, в 21:47
0

@ZanLynx vm.idlezero_enable сам по себе интересен, но, возможно, он просто предотвращает утечку информации. Есть ли API для получения этой нулевой памяти для libc calloc() ? Я предполагаю, что статической нулевой страницы только для чтения достаточно; ошибка записи меняет их с нулевым пулом. Я предполагаю, что другая часть пула предназначена для дисковых буферов?
artless noise 22 дек. 2013, в 18:45
1

@DietrichEpp извините некро, но, например, Windows делает это.
Andreas Grapentin 11 нояб. 2014, в 19:37
0

calloc () в Windows ~ = HeapAlloc (crtheap, HEAP_ZERO_MEMORY, размер)
KindDragon 18 авг. 2015, в 16:03

Показать ещё 7 комментариев

0

На некоторых платформах в некоторых режимах malloc инициализирует память до некоторого обычно ненулевого значения перед ее возвратом, поэтому вторая версия может хорошо инициализировать память дважды

Stewart 22 апр. 2010, в 06:57

Ещё вопросы

Уверены ли вы? Какие системы это делают? Я думал, что большинство ОС просто выключают процессор, когда они простаивают, и обнуляют память по требованию для процессов, которые выделяются, как только они записывают в эту память (но не когда они выделяют ее).
@Dietrich - Не уверен. Я слышал это однажды, и это показалось разумным (и достаточно простым) способом сделать calloc() более эффективным.
Я думаю, что вы, вероятно, не правы, но я не уверен.
@Pierreten - я не могу найти никакой полезной информации о calloc() оптимизациях, и мне не хочется интерпретировать исходный код libc для OP. Можете ли вы найти что-нибудь, чтобы показать, что эта оптимизация не существует / не работает?
@Chris: код, который вы ищете, находится не в коде libc, а в ядре. Libc просто вызывает sbrk или mmmap и знает, что ядро выдает только обнуленную память из этих двух системных вызовов, поэтому оно не обнуляет эту память снова.
@Dietrich: Предполагается, что FreeBSD обнуляет страницы во время простоя: см. Настройку vm.idlezero_enable.
@ZanLynx vm.idlezero_enable сам по себе интересен, но, возможно, он просто предотвращает утечку информации. Есть ли API для получения этой нулевой памяти для libc calloc() ? Я предполагаю, что статической нулевой страницы только для чтения достаточно; ошибка записи меняет их с нулевым пулом. Я предполагаю, что другая часть пула предназначена для дисковых буферов?
@DietrichEpp извините некро, но, например, Windows делает это.
calloc () в Windows ~ = HeapAlloc (crtheap, HEAP_ZERO_MEMORY, размер)

Dietrich Epp · Accepted Answer · 2010-04-22T07-15-00.000Z

Короткий вариант: Всегда используйте calloc() вместо malloc()+memset(). В большинстве случаев они будут одинаковыми. В некоторых случаях calloc() будет работать меньше, потому что он может полностью пропустить memset(). В других случаях calloc() может даже обманывать и не выделять никакой памяти! Однако malloc()+memset() всегда будет выполнять весь объем работы.

Понимание этого требует короткого обзора системы памяти.

Быстрый просмотр памяти

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

Распределители памяти, такие как malloc() и calloc(), в основном, должны принимать небольшие выделения (от 1 байт до 100 с КБ) и группировать их в более крупные пулы памяти. Например, если вы выделяете 16 байт, malloc() сначала попытается получить 16 байтов из одного из своих пулов, а затем запросить больше памяти из ядра, когда пул будет работать сухим. Однако, так как запрошенная вами программа выделяет для большого объема памяти сразу, malloc() и calloc() просто запрашивают эту память непосредственно из ядра. Порог этого поведения зависит от вашей системы, но я видел, что в качестве порога используется 1 MiB.

Ядро отвечает за распределение фактической ОЗУ каждому процессу и обеспечение того, чтобы процессы не мешали памяти других процессов. Это называется защитой памяти, с 1990-х годов она была грязной, и это причина, по которой одна программа может потерпеть крах, не разрушая всю систему. Поэтому, когда программе требуется больше памяти, она не может просто взять память, но вместо этого она запрашивает память из ядра с помощью системного вызова типа mmap() или sbrk(). Ядро выдаст RAM каждому процессу, изменив таблицу страниц.

Таблица страниц отображает адреса памяти в фактическую физическую память. Адреса процессов: от 0x00000000 до 0xFFFFFFFF в 32-битной системе, не являются реальной памятью, а являются адресами в виртуальной памяти. Процессор делит эти адреса на 4 страницы KiB, и каждая страница может быть назначена другой части физической памяти путем изменения таблицы страниц. Только ядру разрешено изменять таблицу страниц.

Как это не работает

Здесь как выделение 256 MiB не работает:

Ваш процесс вызывает calloc() и запрашивает 256 MiB.
Стандартная библиотека вызывает mmap() и запрашивает 256 MiB.
Ядро обнаруживает 256 Мбайт неиспользуемой ОЗУ и передает его вашему процессу, изменяя таблицу страниц.
Стандартная библиотека обнуляет ОЗУ с помощью memset() и возвращает из calloc().
В конечном итоге ваш выход завершается, и ядро восстанавливает RAM, поэтому его можно использовать другим процессом.

Как это работает на самом деле

Вышеупомянутый процесс будет работать, но этого просто не происходит. Существуют три основных отличия.

Когда ваш процесс получает новую память из ядра, эта память, вероятно, ранее использовалась каким-то другим процессом. Это риск для безопасности. Что делать, если в этой памяти есть пароли, ключи шифрования или секретные рецепты сальсы? Чтобы предотвратить утечку конфиденциальных данных, ядро всегда сбрасывает память перед тем, как передать ее процессу. Мы могли бы также очистить память, обнуляя ее, и если новая память обнулена, мы могли бы также сделать ее гарантией, поэтому mmap() гарантирует, что новая память, которую он возвращает, всегда обнуляется.
Есть много программ, которые выделяют память, но не используют память сразу. Иногда память выделяется, но никогда не используется. Ядро это знает и лениво. Когда вы назначаете новую память, ядро не прикасается к таблице страниц вообще и не дает никакой ОЗУ вашему процессу. Вместо этого он находит какое-то адресное пространство в вашем процессе, делает заметку о том, что должно туда идти, и дает обещание, что он поместит RAM там, если ваша программа когда-либо его использует. Когда ваша программа пытается читать или записывать с этих адресов, процессор запускает ошибку страницы и шаги ядра назначают RAM этим адресам и возобновляют вашу программу. Если вы никогда не используете память, ошибка страницы никогда не произойдет, и ваша программа никогда не получит RAM.
Некоторые процессы выделяют память, а затем читают ее, не изменяя ее. Это означает, что много страниц в памяти разных процессов могут быть заполнены нулевыми нулями, возвращаемыми из mmap(). Поскольку эти страницы все одинаковы, ядро делает все эти виртуальные адреса указанием одной общей 4-килобайтовой страницы памяти, заполненной нулями. Если вы попытаетесь записать в эту память, процессор запускает другую ошибку страницы, и ядро запускается, чтобы предоставить вам новую страницу нулей, которая не используется совместно с другими программами.

Последний процесс выглядит примерно так:

Ваш процесс вызывает calloc() и запрашивает 256 MiB.
Стандартная библиотека вызывает mmap() и запрашивает 256 MiB.
Ядро обнаруживает 256 Мбайт неиспользуемого адресного пространства, делает заметку о том, для чего это адресное пространство используется и возвращается.
Стандартная библиотека знает, что результат mmap() всегда заполняется нулями (или будет когда-то на самом деле получить некоторую ОЗУ), поэтому он не касается памяти, поэтому нет ошибки страницы, и оперативная память никогда не предоставляется вашему процессу.
В конечном итоге ваш выход завершается, и ядру не нужно восстанавливать ОЗУ, потому что он никогда не выделялся в первую очередь.

Если вы используете memset() для нулевой страницы, memset() вызовет ошибку страницы, вызовет выделение ОЗУ, а затем нуль, даже если он уже заполнен нулями. Это огромное количество дополнительной работы, и объясняет, почему calloc() быстрее, чем malloc() и memset(). Если все равно использовать память, calloc() все еще быстрее, чем malloc() и memset(), но разница не такая уж смешная.

Это не всегда работает

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

Это также не всегда будет работать с меньшими выделениями. При меньших распределениях, calloc() получает память из общего пула вместо прямого доступа к ядру. В общем случае общий пул может содержать в нем нежелательные данные из старой памяти, которые были использованы и освобождены с помощью free(), поэтому calloc() может взять эту память и вызвать memset(), чтобы очистить ее. Общие реализации будут отслеживать, какие части общего пула являются нетронутыми и все еще заполнены нулями, но не все реализации делают это.

Распространение неверных ответов

В зависимости от операционной системы ядро может или не может иметь нулевую память в свободное время, если вам нужно получить некоторую обнуленную память позже. Linux не нулевая память раньше времени, а Dragonfly BSD недавно также удалила эту функцию из своего ядра. Однако некоторые другие ядра используют нулевую память раньше времени. Нулевых страниц бездействия недостаточно, чтобы объяснить большие различия в производительности.

Функция calloc() не использует некоторую специальную версию memset() с выравниванием по памяти, и в любом случае это не сделает ее намного быстрее. Большинство реализаций memset() для современных процессоров выглядят примерно так:

function memset(dest, c, len)
    // one byte at a time, until the dest is aligned...
    while (len > 0 && ((unsigned int)dest & 15))
        *dest++ = c
        len -= 1
    // now write big chunks at a time (processor-specific)...
    // block size might not be 16, it just pseudocode
    while (len >= 16)
        // some optimized vector code goes here
        // glibc uses SSE2 when available
        dest += 16
        len -= 16
    // the end is not aligned, so one byte at a time
    while (len > 0)
        *dest++ = c
        len -= 1

Итак, вы можете видеть, что memset() работает очень быстро, и вы не собираетесь получать что-либо лучше для больших блоков памяти.

Тот факт, что memset() является обнуляющей память, которая уже обнулена, означает, что память обнуляется дважды, но это только объясняет разницу в производительности 2x. Разница в производительности здесь намного больше (я измерил более трех порядков в моей системе между malloc()+memset() и calloc()).

Трюк участника

Вместо того, чтобы зацикливать 10 раз, напишите программу, которая выделяет память до тех пор, пока malloc() или calloc() не вернет NULL.

Что произойдет, если вы добавите memset()?

@Dietrich: объяснение виртуальной памяти Дитриха о том, что ОС выделяет одну и ту же страницу с нулевым заполнением много раз для calloc, легко проверить. Просто добавьте цикл, который записывает ненужные данные на каждой выделенной странице памяти (достаточно записи одного байта каждые 500 байтов). Общий результат должен стать намного ближе, так как система будет вынуждена действительно распределять разные страницы в обоих случаях.
@kriss: действительно, хотя в большинстве систем достаточно одного байта каждые 4096
На самом деле, calloc() часто является частью набора реализации malloc , и поэтому оптимизирована, чтобы не вызывать bzero при получении памяти из mmap .
@mirabilos: На самом деле реализации имеют тенденцию быть еще более сложными. Память, выделенная mmap() , выделяется большими порциями, поэтому реализация malloc() / calloc() может отслеживать, какие блоки все еще остаются нетронутыми и заполнены нулями. Поэтому calloc() может избежать касания памяти, даже если она не получает память от mmap() , то есть она уже была частью кучи, но еще не использовалась.
@DietrichEpp: да, некоторые реализации могут сделать это. Однако это подвержено ошибкам, поэтому некоторые реализации, такие как omalloc из OpenBSD, предпочитают этого не делать. Это оптимизация скорости, но она требует больших затрат на обслуживание (и аудит кода).
@mirabilos: я также видел реализации с «высокой отметкой», где адреса за пределами определенной точки обнуляются. Я не уверен, что вы имеете в виду под «подверженностью ошибкам» - если вы беспокоитесь о записи приложений в нераспределенную память, то очень мало что можно сделать, чтобы предотвратить коварные ошибки, если не обрабатывать программу грязным щелчком.
Прошу прощения за этот старый ответ, но люди ссылаются на него, утверждая, что он оправдывает общее утверждение о том, что calloc работает быстрее, чем malloc + memset. Calloc иногда будет быстрее. В вашем ответе явно не указано, как работает распределение памяти (например, calloc имеет шанс быть быстрее, только если новая страница выделена и не будет затронута, или возвращаемый буфер никогда раньше не использовался) и оставляет начинающих с неправильно впечатление. В нем также говорится, что здесь используется нулевая страница, и ядро может пропустить, возможно, пропустить отображение страницы. продолжение в следующем комментарии
На mmap ядро НЕ будет ничего отображать. Слепое добавление нулевой страницы и необходимость ее последующей замены другой страницей приведет к снижению производительности. При выполнении теста, выставленного OP, нулевая страница не используется. Как вы заметили, к большинству страниц здесь просто нет доступа, и это приводит к тому, что очень мало отображений. Не могли бы вы уточнить ваш пост, в частности, явно указать, когда calloc может быть быстрее, а также заявить, что выполнение malloc + memset для всего буфера неверно и по умолчанию для memseting все также неправильно? Спасибо
@employeeofthemonth: Первоначально это был просто ответ, чтобы объяснить, что наблюдал OP, а не попытка объяснить различия между malloc() и calloc() в целом. Тем не менее, я полагаю, что уже рассмотрел основные моменты вашего комментария: «Когда вы выделяете достаточно большую область памяти…» - это квалификатор для случаев, когда используются эти приемы, которые делают calloc() быстрее, и в скобках «На самом деле, Ядро может… »объясняет, что mmap() не обязательно отображает память, как вы говорите.
@employeeofthemonth: я обычно пересматриваю ответы, чтобы расширить, уточнить и уточнить формулировку, как только они достигнут разумной аудитории, такой как эта. Поскольку вы обратили на это мое внимание, я, вероятно, сделаю это здесь в ближайшие две недели или около того, но вы можете сделать так много, чтобы не дать людям неправильно истолковать вещи.
@employeeofthemonth: я думаю, что эта ревизия должна охватить это.
Спасибо за редактирование, это почти то, что я имел в виду. Ранее вы заявляете, что всегда используете calloc вместо malloc + memset. Пожалуйста, укажите 1. по умолчанию для malloc 2. если небольшая часть буфера должна быть обнулена, memset эта часть 3. в противном случае используйте calloc. В частности, НЕ используйте malloc + memset весь размер (используйте для этого calloc) и НЕ по умолчанию вызывайте все, так как это мешает таким вещам, как valgrind и статические анализаторы кода (вся память внезапно инициализируется). Кроме этого я думаю, что это хорошо.
@employeeofthemonth: Нет. Эти предложения выходят за рамки. Вопрос в том, чтобы сравнить malloc()+memset() с calloc() .
Это незначительный момент, конечно. Я бы согласился, если бы не люди, которые считают «кальлок быстрее» в качестве оправдания. Я нахожу это по теме достаточно, чтобы упомянуть. Если вы не хотите это отмечать здесь, можете ли вы отредактировать раздел в docs ( stackoverflow.com/documentation/c/4726/memory-management/3632/… ), который делает общее утверждение о том, что calloc быстрее, и рекомендует его использовать? Я попросил улучшить, указав лучшее использование и тот факт, что calloc только для некоторых пользователей быстрее. Это "исправлено", когда некоторые реализации calloc работают быстрее.
Но я не собираюсь настаивать. Еще раз спасибо за внимание к основным моментам моего отзыва.
calloc также не подвержен ошибкам, хотя и не связан со скоростью. То есть, где large_int * large_int может привести к переполнению, calloc(large_int, large_int) возвращает NULL , но malloc(large_int * large_int) - неопределенное поведение, поскольку вы не знаете фактический размер возвращаемого блока памяти.