под сабжем подразумеваю:
1. буфера могут быть произвольного размера
2. аллоцирование буфера(если свободных в pool`е нет)
3. возврат буфера в pool
4. выдача свободного буфера из pool`а по минимально необходимому размеру.
кто что юзал?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>под сабжем подразумеваю: X>1. буфера могут быть произвольного размера X>2. аллоцирование буфера(если свободных в pool`е нет) X>3. возврат буфера в pool X>4. выдача свободного буфера из pool`а по минимально необходимому размеру. X>кто что юзал?
Здравствуйте, AleksandrN, Вы писали:
AN>А в чём тогда смысл пула?
пулы бывают не только фиксед-сайз.
если в пуле нет свободных буферов, или буфе слишком мал — аллоцируем новый и кладем в пул.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
AN>>А в чём тогда смысл пула? X>пулы бывают не только фиксед-сайз. X>если в пуле нет свободных буферов, или буфе слишком мал — аллоцируем новый и кладем в пул.
Ты не поверишь, но malloc делает именно это.
Тебе зачем нужен отдельный аллокатор, который просто повторяет функционал malloc? Тут даже каких-то послаблений типа фиксированного размера нет, у тебя по требованиям обычный general purpose memory manager. Может, он однопоточный, или есть ограничение сверху?
Здравствуйте, andrey.desman, Вы писали:
AD>Тебе зачем нужен отдельный аллокатор, который просто повторяет функционал malloc? Тут даже каких-то послаблений типа фиксированного размера нет, у тебя по требованиям обычный general purpose memory manager. Может, он однопоточный, или есть ограничение сверху?
да так, от скуки =)есть необходимость уменьшить кол-во сисколов.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, andrey.desman, Вы писали:
AD>Сам глянь. Точнее, ты же по идее уже глянул...
лет шесть тому.
AD>Я ж не знаю, может у тебя там буферы метровые и их мапать приходится.
удачи.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, andrey.desman, Вы писали:
AD>>Тебе зачем нужен отдельный аллокатор, который просто повторяет функционал malloc? Тут даже каких-то послаблений типа фиксированного размера нет, у тебя по требованиям обычный general purpose memory manager. Может, он однопоточный, или есть ограничение сверху?
X>да так, от скуки =)есть необходимость уменьшить кол-во сисколов.
Тогда почему бы просто не аллоцировать большой кусок с помощью "new",
заполнить его нулями и сделать delete, на это потребуется всего несколько системных
вызовов, а потом аллокатор просто будет переиспользовать этот кусок памяти,
не обращаясь к ОС.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, andrey.desman, Вы писали:
AD>>Тебе зачем нужен отдельный аллокатор, который просто повторяет функционал malloc? Тут даже каких-то послаблений типа фиксированного размера нет, у тебя по требованиям обычный general purpose memory manager. Может, он однопоточный, или есть ограничение сверху?
X>да так, от скуки =)есть необходимость уменьшить кол-во сисколов.
Так есть же кастомные аллокаторы, которые подобным и занимаются: один раз дёрбанят у ОС жирный кусок памяти, а затем ведут свою "чёрную кассу" кто кому что должен из памяти. Вплоть до пре-аллоцирования N пулов буферов размером от 1 до N байт (а всё что выше — берётся из отдельного large heap). Идея весьма старая, ещё в 90-х с этим сталкивался.
Здравствуйте, Zhendos, Вы писали:
Z>Тогда почему бы просто не аллоцировать большой кусок с помощью "new", Z>заполнить его нулями и сделать delete, на это потребуется всего несколько системных Z>вызовов, а потом аллокатор просто будет переиспользовать этот кусок памяти, Z>не обращаясь к ОС.
А зачем его бить нулями? Лишняя работа плюс убийство кэша CPU (разве что через DMA это лить, но тут уже сам себе Ржевский).
Здравствуйте, Zhendos, Вы писали:
Z>Тогда почему бы просто не аллоцировать большой кусок с помощью "new", Z>заполнить его нулями и сделать delete, на это потребуется всего несколько системных Z>вызовов, а потом аллокатор просто будет переиспользовать этот кусок памяти, Z>не обращаясь к ОС.
я думал об этом, но это как-то не очевидно, и чем-то напоминает хак...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>кто что юзал?
На ум приходят только кастомные аллокаторы, может быть boost::pool_alloc, но они все работают по принципу отожрать много памяти, а потом распределять её со всеми минусами.
Здравствуйте, Zhendos, Вы писали:
Z>Тогда почему бы просто не аллоцировать большой кусок с помощью "new", Z>заполнить его нулями и сделать delete, на это потребуется всего несколько системных Z>вызовов, а потом аллокатор просто будет переиспользовать этот кусок памяти, Z>не обращаясь к ОС.
Это от libc зависит. На каком-нибудь uClibc все, что выше 128К всегда будет выделяться mmap/munmap. glibc же будет этот порог увеличивать с каждым разом, так что там в принципе ничего особого делать и не надо.
