Масштабируемое распределение памяти - PullRequest
8 голосов
/ 25 марта 2010

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

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

Ответы [ 4 ]

5 голосов
/ 04 апреля 2010

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

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

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


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


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

4 голосов
/ 30 марта 2010

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

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

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

1 голос
/ 12 августа 2010

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

1 голос
/ 02 апреля 2010

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

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

...