Может ли многопоточность ускорить выделение памяти?

Динамическое выделение памяти использует кучу приложения/модуля/процесса (но не поток). Куча может обрабатывать только один запрос на выделение за раз. Если вы попытаетесь выделить память в «параллельных» потоках, они будут обрабатываться кучей в должном порядке. Вы не получите такого поведения, как: один поток ждет, чтобы получить свою память, в то время как другой может запросить часть, а третий получает часть. Потоки должны будут выстроиться в очередь, чтобы получить свой кусок памяти.

Что вам нужно, так это пул куч. Используйте ту кучу, которая не занята в данный момент, для выделения памяти. Но затем вы должны следить за тем, чтобы эта переменная не была освобождена в другой куче (это может привести к сбою).

Я знаю, что Win32 API имеет такие функции, как GetProcessHeap(), CreateHeap(), HeapAlloc() и HeapFree(), которые позволяют создавать новую кучу и выделять/освобождать память из определенной HANDLE кучи. Я не знаю эквивалента в других операционных системах (я искал их, но безрезультатно).

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

Стандартный ЭЛТ

Хотя в более ранних версиях Visual Studio распределитель CRT по умолчанию блокировался, это уже не так, по крайней мере, для Visual Studio 2010 и новее, которые напрямую вызывают соответствующие функции ОС. Диспетчер кучи Windows блокировал до Windows XP, в XP необязательный Low Fragmentation Heap не блокирует, в то время как куча по умолчанию блокирует, а более новые ОС (Vista/Win7) используют LFH по умолчанию. Производительность последних (Windows 7) распределителей очень хорошая, сравнимая с масштабируемыми заменами, перечисленными ниже (вы все равно можете предпочесть их, если ориентируетесь на более старые платформы или когда вам нужны некоторые другие функции, которые они предоставляют). Существует несколько множественных «масштабируемых распределителей» с разными лицензиями и разными недостатками. Я думаю, что в Linux библиотека времени выполнения по умолчанию уже использует масштабируемый распределитель (некоторый вариант PTMalloc).

Масштабируемые замены

Я знаю о:

• HOARD (GNU + коммерческие лицензии)
• MicroQuill SmartHeap для SMP (коммерческая лицензия)
• Инструменты Google Perf Tools TCMalloc (лицензия BSD)
• NedMalloc (лицензия BSD)
• JemAlloc (лицензия BSD)
• PTMalloc (GNU, еще нет порта для Windows?)
• Intel Thread Building Blocks (GNU, коммерческая версия)

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

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

Есть 2 масштабируемые замены для malloc, о которых я знаю:

• tcmalloc от Google
• Facebook jemalloc (ссылка на исследование производительности по сравнению с tcmalloc)

У меня нет никакого опыта работы с Hoard (который показал плохие результаты в исследовании), но Эмери Бергер сомневается в этом. сайте и был поражен результатами. Он сказал, что посмотрит, и я предполагаю, что в тесте или реализации могли быть какие-то особенности, которые «заманили» Хоарда в ловушку, поскольку общие отзывы обычно хорошие.

Одно слово предостережения с jemalloc, это может занять немного места, когда вы быстро создаете, а затем отбрасываете потоки (поскольку он создает новый пул для каждого потока, из которого вы выделяете). Если ваши потоки стабильны, с этим не должно быть никаких проблем.

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

Помимо вашего вопроса и ответов, уже опубликованных здесь, было бы хорошо начать с ваших ожиданий в отношении улучшений, потому что это в значительной степени подскажет, какой путь выбрать. Возможно, вам нужно быть в 100 раз быстрее. Кроме того, планируете ли вы в ближайшем будущем заняться улучшением скорости или есть какой-то уровень, которого будет достаточно? Не зная вашего приложения или проблемной области, трудно также дать вам конкретный совет. Например, вы находитесь в проблемной области, где скорость должна постоянно улучшаться?

При улучшении производительности стоит начать с вопроса задать вопрос, нужно ли вам делать что-то так, как вы это делаете сейчас? В этом случае можете ли вы предварительно выделить объекты? Существует ли максимальное количество объектов X в системе? Можно ли повторно использовать объекты? Все это лучше, потому что вам не обязательно делать выделения на критическом пути. Например. если вы можете повторно использовать объекты, пользовательский распределитель с предварительно выделенными объектами будет работать хорошо. Кроме того, на какой ОС вы работаете?

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

Удачи!

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

(вы можете переопределить новое и удалить)

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

ограничьте свои потоки количеством доступных ядер.

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

Распределение памяти происходит медленно — если вы делаете это несколько раз, особенно на большом количестве потоков, вам нужен редизайн. Можете ли вы заранее выделить достаточно места в начале, можете ли вы просто выделить большой кусок с «новым», а затем разбить его самостоятельно?

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

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

Конечно, в этом случае, возможно, стоит задаться вопросом, действительно ли вам нужно выделение кучи, а не какая-либо другая форма динамического распределения.

Вы можете взглянуть на распределитель памяти Hoard: "является заменой malloc() это может значительно повысить производительность приложений, особенно для многопоточных программ, работающих на многопроцессорных компьютерах».

1. Лучшее, что вы можете попытаться достичь ~8 распределения памяти параллельно (так как у вас 8 физических ядер), а не 10000, как вы написали

2. стандартный malloc использует мьютекс, и стандартный распределитель STL делает то же самое. Поэтому он не будет автоматически ускоряться, когда вы вводите многопоточность. Тем не менее, вы можете использовать другую библиотеку malloc (погуглите, например, «ptmalloc»), которая не использует глобальную блокировку. если вы выделяете с помощью STL (например, выделяете строки, векторы), вам нужно написать свой собственный распределитель.

Довольно интересная статья: http://developers.sun.com/solaris/articles/multiproc/multiproc.html