Масштабируемые события средства выделения памяти
Я в настоящее время оцениваю несколько масштабируемых средств выделения памяти, а именно, nedmalloc и ptmalloc (оба созданные сверху dlmalloc), как замена для значения по умолчанию malloc / новый из-за значительной конкуренции, замеченной в многопоточной среде. Их опубликованная производительность, кажется, хороша, однако я хотел бы проверить то, что является событиями других людей, которые действительно использовали их.
- Ваши цели производительности были удовлетворены?
- Вы испытывали кого-либо неожиданного или твердого решить проблемы (как повреждение "кучи")?
- Если Вы попробовали и ptmaalloc и nedmalloc, который из этих двух Вы рекомендовали бы? Почему (простота использования, производительность)?
- Или возможно Вы рекомендовали бы другое масштабируемое средство выделения (свободный с допустимой предпочтенной лицензией)?
4 ответа
Я внедрил NedMalloc в наше приложение и вполне доволен результатами. Разногласия, которые я видел раньше, исчезли, и распределитель было довольно легко подключить, даже общая производительность была очень хорошей, до момента, когда накладные расходы на выделение памяти отсутствуют, приложение теперь почти не поддается измерению.
Я не пробовал ptmalloc, так как я не нашел его версию для Windows, и я потерял мотивацию, когда NedMalloc работал у меня нормально.
Помимо двух упомянутых, я думаю, что было бы также интересно попробовать TCMalloc - он имеет некоторые функции, которые теоретически звучат лучше, чем NedMalloc (например, очень небольшие накладные расходы на небольшие выделения по сравнению с 4 B заголовок, используемый NedMalloc), однако, поскольку он, похоже, не имеет готового порта для Windows, это также может оказаться не совсем простым.
После нескольких недель использования NedMalloc я был вынужден отказаться от него, потому что его накладные расходы на пространство оказались для нас слишком высокими. Что нас особенно поразило, так это то, что NedMalloc, похоже, восстанавливает память, которую он больше не использует в ОС, в плохом состоянии, сохраняя большую часть памяти. На данный момент я заменил его на JEMalloc , который кажется не таким быстрым (он все еще быстр, но не так быстро, как NedMalloc), но он очень надежен в этом отношении и его масштабируемость также очень хороший.
И после нескольких месяцев использования JEMalloc я перешел на TCMalloc. Чтобы адаптировать его для Windows, потребовалось больше усилий по сравнению с другими, но его результаты (как производительность, так и фрагментация) кажутся лучшими для нас из того, что я тестировал до сих пор.
Раньше мне требовался очень быстрый метод выделения памяти. Я обнаружил, что не было выделенного на работу ассигнования.
Через пару дней поиска я наткнулся на boost :: pool, который мы в нашем приложении дали прирост производительности в 300 раз.
Мы просто вызываем malloc / free для объектов, которые хотим создать. Хотя есть небольшие накладные расходы на настройку, с необходимостью для начала выделить большой объем памяти, но как только это будет сделано, это будет очень быстро.
Некоторое время назад я пытался пойти вашим путем, когда столкнулся с многопоточным конфликтом и серьезной проблемой фрагментации. После небольшого тестирования я пришел к выводу, что преимущества этих распределителей незначительны в большинстве интересных случаев, которые у меня были.
Настоящим решением было использование моего собственного менеджера памяти, который был специализирован для задач, которые я выполнял чаще всего.
Если вы используете Win32, мой опыт показывает, что трудно превзойти обычный диспетчер кучи Windows при условии, что вы включить низкую фрагментацию кучи с помощью API HeapSetInformation. Я считаю, что теперь это стандарт для новых версий Windows. Он обрабатывает блокировку с использованием примитивов Interlocked * Win32, а не более простой блокировки Mutex / CritSec.