Опыт масштабируемого распределения памяти

Question

В настоящее время я оцениваю несколько масштабируемых распределителей памяти, а именно nedmalloc и ptmalloc (оба построены поверх dlmalloc) в качестве замены для malloc/new по умолчанию из-за значительного разногласия, наблюдаемого в многопоточной среде. Их опубликованная производительность кажется хорошей, однако я хотел бы проверить, что такое опыт других людей, которые действительно использовали их.

• Были ли удовлетворены ваши цели выполнения?
• Испытывали ли вы какие-либо неожиданные или трудные для решения проблемы (например, кучное повреждение)?
• Если вы попробовали как ptmaalloc, так и nedmalloc, какой из двух вы порекомендовали бы? Почему (простота использования, производительность)?
• Или, может быть, вы порекомендовали бы другой масштабируемый распределитель (бесплатный с допустимой лицензией)?

Answer 1

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

Я не пробовал ptmalloc, так как я не нашел его готовой к Windows версии, и я потерял мотивацию, как только NedMalloc отлично справился со мной.

Помимо двух упомянутых, я думаю, было бы также интересно попробовать TCMalloc - у него есть некоторые функции, которые лучше звучат лучше, чем NedMalloc в теории (например, очень небольшие накладные расходы для небольших распределений по сравнению с заголовком 4 B, используемым NedMalloc) , однако, поскольку он, похоже, не готов к работе с портом Windows, он также может оказаться не совсем простым.

---

После нескольких недель использования NedMalloc я был вынужден отказаться от него, потому что его пространство над головой оказалась слишком высокой для нас. Что особенно поразило нас, NedMalloc, по-видимому, восстанавливает память, которую он больше не использует для ОС, не дожидаясь, пока большая часть ее еще не выполнена. На данный момент я заменил его на JEMalloc, который, кажется, не так быстр (он все еще быстрый, но не так быстро, как NedMalloc был), но он очень устойчив в этом манере, и его масштабируемость также очень хороша.

---

И после нескольких месяцев использования JEMalloc я перешел на TCMalloc.Потребовалось больше усилий, чтобы адаптировать его для Windows по сравнению с другими, но его результаты (как производительность, так и фрагментация) кажутся лучшими для нас тем, что я тестировал до сих пор.

Answer 2

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

После нескольких дней поиска я столкнулся с boost :: pool, который мы в нашем приложении дали увеличение производительности в 300 раз.

Мы аффективно просто вызываем malloc/free на объекты, которые хотим создать. Хотя есть небольшие накладные расходы на настройку, и для этого нужно сначала скомпилировать большой объем памяти, но как только это будет сделано, это очень быстро.

Answer 3

Я попытался пройти ваш путь некоторое время назад, столкнувшись с многопоточным конфликтом и серьезной проблемой фрагментации. После довольно неудачного тестирования я пришел к выводу, что преимущество этих распределителей незначительно в большинстве интересных случаев, которые у меня были.

Реальное решение заключалось в том, чтобы вытащить моего собственного менеджера памяти, который был специализирован на задачах, которые я делал чаще всего.

Answer 4

Если вы работаете в Win32, мой опыт состоял в том, что трудно обыгрывать обычный кустарник Windows при условии, что вы включите кукурузу с низкой фрагментацией с использованием API-интерфейса HeapSetInformation. Я считаю, что теперь это стандарт для новых версий Windows. Он управляет блокировкой с использованием Interlocked * Win32-примитивов, а не более простой блокировкой Mutex/CritSec.