Здравствуйте, vdimas, Вы писали:

V>Делит куски памяти по основанию 2? Адрес страницы вычисляет округлением младших бит?
V>Просто любопытно... бо, судя по всему, придется попробовать нарисовать аналогичное. Хорошо ли показывает себя для std::string?
V>Я так понимаю, что надо резервировать выровненные области памяти на всяк случай и потом коммитить по мере надобности?

Аллокатор, про который ты говоришь называется buddy. Он очень быстрый, но у него много проблем, в частности, я люблю такие контейнеры, которые аллокируют память кусками типа 256 байт, в общем, по степени двойки, типа std::deque, только более гибкие и простые. Но из за хедеров эти аллокации получаются самыми вредными, там практически двойные потери памяти. А я придумал аллокатор на бит-сетах, и о нем уже рассказывал. А Миха придумал как резолвить адреса через таблицы. Для 32 бит достаточно 2-х уровневой таблицы, для x64 надо 5-уровневую. Таблицы требуют примерно 0.2% аллокируемой памяти, бит-сеты около 3%. Это очень хорошо для большого количества мелких аллокаций, но плохо для больших. Мы посчитали — dlmalloc где-то вдвое больше памяти жрет на ActionScript. Но засада нашей идеи в том, что нужен алаймент на 4K в SysAlloc, типа как в mmap или VirtualAlloc. А это для клиентов оказалась гигантская попоболь, потому что они всегда подсовывают что-то свое, которое не алайнится так просто.

Здравствуйте, minorlogic, Вы писали:

M>Я больше спрашивал , сравнивали ли с всякими хорошо известными реализациями , мне первым http://www.hoard.org/ в голову приходить

Я знаю про Хоард и мы с ним сравнивали, у нас немного хуже по скорости, процентов на 30. Но главная фишка — функция AllocAutoHeap. Это когда много хипов, но при этом не надо везде таскать адрес хипа, он прекрасно и быстро резолвится по указателю this. Понятно, что в стэке такие объекты не создашь, только динамически, но для этого прекрасно служат всякие смарт-поинтеры.

Здравствуйте, 0x8000FFFF, Вы писали:

FFF>Никогда не пишите библиотек, а решайте основную задачу. Если ограничиваться только своим кусочком — такие ситуации всегда будут.. .

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

Здравствуйте, SilentNoise, Вы писали:

SN>Если так нужны выравнивания, не лучше ли явно отразить это в API и сделать аналог posix_memalign?

Я за это и ратовал, что нужны локальные решения а не глобальные. Но авторитет руководства оказался сильнее.
У меня вообще свои контейнеры, которые обращаются с памятью очень нежно и ласково. А если кто-то скажет про велосипед, то отвечу, что этот велосипед — 2-3% всего кода и примерно 0.1% времени от разработки алгоритма. Такие дела.