Войти
ПрограммированиеФорумОбщее

Мультипоточное управление памятью (2 стр)

Страницы: 1 2
#15
18:53, 1 дек. 2019

BingoBongo

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


#16
19:05, 1 дек. 2019

Если тебе нужно alloc/dealloc мелких объектов, часто, да еще в разных потоках, то это какой-то бред. Ты уверен, что это быстрее мемори/обжект пула в 1 потоке?

#17
19:08, 1 дек. 2019

innuendo
> приходи, поговорим
Боюсь, через пару недель в твою дверь постучится разве что дождь.

#18
19:19, 1 дек. 2019

lookid
> Если тебе нужно alloc/dealloc мелких объектов, часто, да еще в разных потоках
На постоянно основе нет. Вся основная работа происходит в конкретном потоке, просто потом эти данные используются дальше в другом потоке, и только другой поток может их освободить. Вообще, предлагаю не задаваться вопросами зачем и почему относительно задачи, а то получится как в анекдоте про мужика, который пришел за прокладками жене.

#19
19:21, 1 дек. 2019

BingoBongo
> и только другой поток может их освободить.
вот пусть этот передаст тому и тот удалит как белый человек

#20
19:26, 1 дек. 2019

BingoBongo
Покажи реализацию своего "аллокатора"

#21
19:37, 1 дек. 2019

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

Более адекватное решение - это перед завершением работы скопировать результат в malloc() память, и сразу удалить то что было выделено в потоке. Однако, в моем частном случае копировать надо достаточно сложную структуру. К тому же с учетом некоторых хороших ответов можно все таки сделать мультипоточный аллокатор, так что ничего копировать не придется, и производительность особо не изменится.

maks242
> Покажи реализацию своего "аллокатора"
Свой аллокатор, знаешь ли, нельзя показывать кому попало, такое доверие надо сначала заслужить )

#22
20:18, 1 дек. 2019

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

#23
20:21, 1 дек. 2019

BingoBongo

ok, как сделаешь - расскажешь подробно

#24
21:06, 1 дек. 2019

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

По-моему, мы уже там. "Прокладки нужны жене, но пользоваться ими будет не она".
#25
21:32, 1 дек. 2019
NyakNyakProduction
> По-моему, мы
Кто о чем, а вас только прокладки интересуют
#26
(Правка: 2:41) 2:16, 2 дек. 2019

BingoBongo

> Существует ли реализация, при которой работа аллокатора будет быстрее, чем просто вызовы malloc()/free() ?

Обычно, в таких ситуациях быстрее http://jemalloc.net/. Можно ещё попробовать https://github.com/microsoft/mimalloc. Скорее всего будет быстрее "стандартной" реализации. Как только у вас паттерн работы с памятью поменяется — производительность аллокатора тоже изменится. Они все заточены под какой-то набор конкретных "use-case".

> Объем этой памяти соизмерим с размером L3 кеша

Это как? Размер кэша между разными моделями CPU меняется в разы. Закладываться на него можно только когда мы делаем под жестко фиксированную платформу (читай консоли). Во всех остальных случаях используются алгоритмы не зависящие от размеров кэша (cache-oblivious).

> Аллокации происходят очень часто

Если вы упираетесь в производительность аллокатора при работе внутри основного цикла, нужно подумать на тему предаллокации памяти. Или использовать аллокаторы фиксированного размера. На них можно получить производительность в O(1) даже в многозадачной системе.

> Я боюсь, при частых аллокациях атомики напрочь убью производительность. Это не так?

На современных CPU — это не так.

#27
11:49, 2 дек. 2019

nbkolchin
> Это как? Размер кэша между разными моделями CPU меняется в разы
Где я читал было от 8 до 50 Мб. Так написано, чтобы никто не подумал, что размер какой-то нестандартный, и сама задача из-за этого узкоспециализированная.

> нужно подумать на тему предаллокации памяти.
Предаллокация невозможна, фиксированные блоки - это да, попробую реализовать.

#28
19:59, 2 дек. 2019

BingoBongo

Мультипоточное управление памятью

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

также выделяемые потоки приложения должны сами схлопываться при исчезновении приложения
без мастер хендла поток в аут : собственно незачем контролировать какие-то участки кроме
тотала памяти на приложение или там свободной памяти - знать скока можно подгрузить ресурсов

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

Страницы: 1 2
ПрограммированиеФорумОбщее