Использование realloc в C++

Question

std::realloc является опасным в C++, если память malloc'd содержит не-типы. Кажется, только проблема в том, что std::realloc не вызовет тип деструкторов, если он не может вырастить память на месте.

Тривиальная работа вокруг была бы функцией try_realloc. Вместо того чтобы malloc'ing новой памяти, если она не может быть выращена in situ, она просто вернет false. В этом случае можно было бы выделить новую память, объекты, скопированные (или перемещенные) в новую память, и, наконец, освобожденную память.

Это кажется чрезвычайно полезным. std::vector может очень использовать это, возможно, избегая всех копий/перераспределений.
Упреждающее огнезащитное средство: Технически это то же самое, что и у Big-O, но если рост вектора - это горло бутылки в вашем приложении, скорость x2 хороша, даже если Big-O остается неизменным.

НО, я не могу найти какой-либо c api, который работает как try_realloc.

Я что-то упустил? try_realloc не так полезен, как я себе представляю? Есть ли скрытая ошибка, которая делает try_realloc непригодной для использования?

Еще лучше, есть ли менее документированный API, который работает как try_realloc?

ПРИМЕЧАНИЕ: Я, очевидно, в коде библиотеки/платформы. Я не волнуюсь, так как try_realloc по своей сути является оптимизацией.

---

Update: После Стив Jessops комментарий по вопросу о том vector будет более эффективным использованием перераспределить я написал доказательство концепции для проверки. realloc-vector имитирует шаблон роста вектора, но имеет возможность повторно использовать вместо него. Я запустил программу до миллиона элементов в векторе.

Для сравнения a vector должен выделять 19 раз, увеличивая до миллиона элементов.

Результаты, если realloc-vector - это единственная вещь, использующая кучу, результаты являются удивительными, 3-4 выделения при увеличении до миллиона байт.

Если realloc-vector используется вместе с vector, который растет на 66% скорости в realloc-vector результаты менее многообещающим, выделяя 8-10 раз во время роста.

И наконец, если realloc-vector используется вместе с vector, который растет с той же скоростью, realloc-vector выделяет 17-18 раз. Едва экономя одно распределение над стандартным поведением вектора.

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

Answer 1

vector обычно растет большими приращениями. Вы не можете делать это многократно, не пересаживаясь, если вы не тщательно упорядочиваете вещи так, чтобы в большом объеме были бесплатные адреса чуть выше внутреннего буфера вектора (что фактически требует назначения целых страниц, потому что, очевидно, вы не можете иметь другие распределения позже на той же странице).

Так что я думаю, что для того, чтобы получить действительно хорошую оптимизацию, вам потребуется больше, чем «тривиальный обходной путь», что делает дешевую перераспределению, если это возможно - вы должны каким-то образом сделать некоторые приготовления к сделать возможным, и что подготовка стоит вам адрес пространства. Если вы делаете это только для определенных векторов, которые указывают, что они станут большими, то это довольно бессмысленно, потому что они могут указать reserve(), что они станут большими. Вы можете делать это автоматически только для всех векторов, если у вас обширное адресное пространство, чтобы вы могли «отбросить» большой кусок его на каждый вектор.

Как я понимаю, причина, по которой концепция Allocator не имеет функции перераспределения, заключается в ее простоте. Если std::allocator имеет функцию try_realloc, то либо каждый Allocator должен иметь один (который в большинстве случаев не может быть реализован, а просто должен всегда возвращать false), либо каждый стандартный контейнер должен быть специализирован для std::allocator воспользуйтесь этим. Ни один из вариантов не является отличным интерфейсом Allocator, хотя я полагаю, что это не было бы огромным усилием для разработчиков почти всех классов Allocator просто для добавления функции try_realloc do-nothing.

Если vector является медленным из-за перераспределения, deque может быть хорошей заменой.

Answer 2

Вы могли бы реализовать что-то вроде try_realloc вы предложили, используя mmap с MAP_ANONYMOUS и MAP_FIXED и mremap с MREMAP_FIXED.

Edit: только что заметил, что страница для mremap даже говорит:

mremap() использует таблицы страниц схемы Linux. mremap() изменяет отображение между виртуальными адресами и страницами памяти. Это можно использовать для реализации очень эффективного realloc (3).

Answer 3

realloc in C - это не более чем функция удобства; он имеет очень мало преимуществ для производительности/сокращения копий. Основное исключение, о котором я могу думать, это код, который выделяет большой массив, а затем уменьшает размер, как только необходимый размер известен, но даже это может потребовать переноса данных на некоторые версии malloc (те, которые разделяют блоки строго по размеру), поэтому я рассматриваю это использование realloc действительно плохая практика.

Если вы не постоянно перераспределяете свой массив каждый раз, когда добавляете элемент, но вместо этого увеличиваете его экспоненциально (например, на 25%, 50% или 100%), когда вы исчерпаете пространство, просто вручную выделение новой памяти, копирование и освобождение старого приведет к примерно одинаковой (и идентичной, в случае фрагментации памяти) производительности с использованием realloc. Это, безусловно, подход, который использует реализация C++ STL, поэтому я думаю, что вся ваша забота необоснованна.

Edit: Один (редко, но не неслыханное) случай, когда realloc на самом деле полезно для гигантских блоков в системах с виртуальной памятью, где библиотека C взаимодействует с ядром переместить целые страницы на новые адреса.Причина, по которой я говорю это редко, заключается в том, что вам нужно иметь дело с очень большими блоками (по крайней мере, несколько сотен kB), прежде чем большинство реализаций войдут в сферу управления распределением страницы и, вероятно, намного больше (возможно, несколько MB) перед входом и выходом из ядра для переупорядочения виртуальной памяти дешевле, чем просто делать копию. Конечно, try_realloc здесь не был бы здесь полезен, так как вся польза исходит от фактически делает ход недорого.