Сообщение Re: Посоветуйте однопоточную кучу. от 16.09.2022 8:58
Изменено 16.09.2022 11:36 vopl
Re: Посоветуйте однопоточную кучу.
Здравствуйте, Went, Вы писали:
W>Здравствуйте.
W>В рамках одного эксперимента нуждаюсь в готовой реализации однопоточной (то есть без синхронизации) куче, не заточенной под объекты какого-то определенного размера, но при этом разумно оптимизированной по скорости. Понятно, что можно и самому написать, но зачем тратить время на велосипед? Всё что надо, чтобы делала malloc, free, и, по необходимости, лезла в физическую кучу за новым куском памяти. Буду благодарен за любую наводку.
Выше предлагали посмотреть unsynchronized_pool_resource.. Когда то давным давно делал подобную штуку для своих целей, отличия от unsynchronized_pool_resource примерно такие:
1. при отвобождении памяти она возвращается в систему (в unsynchronized_pool_resource нет)
2. для освобождения нужно передать только указатель на блок памяти (в unsynchronized_pool_resource надо передать указатель + размер/выравниваение)
3. размер выделяемого блока можно задавать не только в рантайме, но и в compile time, это ускоряет выделение (в unsynchronized_pool_resource — только в рантайм)
4. некоторые арифметические моменты упразднены в силу структуры лайаута низлежащей памяти, что экономит некоторое количество арифметики (в unsynchronized_pool_resource такая арифметика делается в рантайме)
5. разбивка на пулы линейная а не геометрическая, это уменьшает перерасход памяти (в unsynchronized_pool_resource геометрическая)
6. (это скорее минус) адресное пространство под кучу выделяется целиком и сразу (иногда это приводит к проблемам с valgrind, с дампилкой gdb/gcore)
7. (это скорее минус) на 32бит-платформе не вполне эффективно, так как заранее забирает себе много адресного пространства и остальным не хватает. А вот на 64бит — в самый раз
8. (это скорее минус) в имеющемся виде вряд ли будет работать под виндой, там сейчас используется posix mmap/mptotect (но нет противопоказаний переписать на VirtualAlloc, есть работающий пример в другом проекте, если интересно)
АПИ тут https://github.com/vopl/heap3/blob/master/include/mm.hpp
в общем, эта штука очень хорошо себя показывает как однопочная куча для мелкогранулярных высокочастотных аллокаций.
W>Здравствуйте.
W>В рамках одного эксперимента нуждаюсь в готовой реализации однопоточной (то есть без синхронизации) куче, не заточенной под объекты какого-то определенного размера, но при этом разумно оптимизированной по скорости. Понятно, что можно и самому написать, но зачем тратить время на велосипед? Всё что надо, чтобы делала malloc, free, и, по необходимости, лезла в физическую кучу за новым куском памяти. Буду благодарен за любую наводку.
Выше предлагали посмотреть unsynchronized_pool_resource.. Когда то давным давно делал подобную штуку для своих целей, отличия от unsynchronized_pool_resource примерно такие:
1. при отвобождении памяти она возвращается в систему (в unsynchronized_pool_resource нет)
2. для освобождения нужно передать только указатель на блок памяти (в unsynchronized_pool_resource надо передать указатель + размер/выравниваение)
3. размер выделяемого блока можно задавать не только в рантайме, но и в compile time, это ускоряет выделение (в unsynchronized_pool_resource — только в рантайм)
4. некоторые арифметические моменты упразднены в силу структуры лайаута низлежащей памяти, что экономит некоторое количество арифметики (в unsynchronized_pool_resource такая арифметика делается в рантайме)
5. разбивка на пулы линейная а не геометрическая, это уменьшает перерасход памяти (в unsynchronized_pool_resource геометрическая)
6. (это скорее минус) адресное пространство под кучу выделяется целиком и сразу (иногда это приводит к проблемам с valgrind, с дампилкой gdb/gcore)
7. (это скорее минус) на 32бит-платформе не вполне эффективно, так как заранее забирает себе много адресного пространства и остальным не хватает. А вот на 64бит — в самый раз
8. (это скорее минус) в имеющемся виде вряд ли будет работать под виндой, там сейчас используется posix mmap/mptotect (но нет противопоказаний переписать на VirtualAlloc, есть работающий пример в другом проекте, если интересно)
АПИ тут https://github.com/vopl/heap3/blob/master/include/mm.hpp
в общем, эта штука очень хорошо себя показывает как однопочная куча для мелкогранулярных высокочастотных аллокаций.
Re: Посоветуйте однопоточную кучу.
Здравствуйте, Went, Вы писали:
W>Здравствуйте.
W>В рамках одного эксперимента нуждаюсь в готовой реализации однопоточной (то есть без синхронизации) куче, не заточенной под объекты какого-то определенного размера, но при этом разумно оптимизированной по скорости. Понятно, что можно и самому написать, но зачем тратить время на велосипед? Всё что надо, чтобы делала malloc, free, и, по необходимости, лезла в физическую кучу за новым куском памяти. Буду благодарен за любую наводку.
Выше предлагали посмотреть unsynchronized_pool_resource.. Когда то давным давно делал подобную штуку для своих целей, отличия от unsynchronized_pool_resource примерно такие:
1. при освобождении памяти она возвращается в систему (в unsynchronized_pool_resource нет)
2. для освобождения нужно передать только указатель на блок памяти (в unsynchronized_pool_resource надо передать указатель + размер/выравниваение)
3. размер выделяемого блока можно задавать не только в рантайме, но и в compile time, это ускоряет выделение (в unsynchronized_pool_resource — только в рантайм)
4. некоторые арифметические моменты упразднены в силу структуры лайаута низлежащей памяти, что экономит некоторое количество вычислений (в unsynchronized_pool_resource такая арифметика делается в рантайме)
5. разбивка на пулы линейная а не геометрическая, это уменьшает перерасход памяти (в unsynchronized_pool_resource геометрическая)
6. (это скорее минус) адресное пространство под кучу выделяется целиком и сразу (иногда это приводит к проблемам с valgrind, с дампилкой gdb/gcore)
7. (это скорее минус) на 32бит-платформе не вполне эффективно, так как заранее забирает себе много адресного пространства и остальным не хватает. А вот на 64бит — в самый раз
8. (это скорее минус) в имеющемся виде вряд ли будет работать под виндой, там сейчас используется posix mmap/mptotect (но нет противопоказаний переписать на VirtualAlloc, есть работающий пример в другом проекте, если интересно)
АПИ тут https://github.com/vopl/heap3/blob/master/include/mm.hpp
в общем, эта штука очень хорошо себя показывает как однопочная куча для мелкогранулярных высокочастотных аллокаций.
W>Здравствуйте.
W>В рамках одного эксперимента нуждаюсь в готовой реализации однопоточной (то есть без синхронизации) куче, не заточенной под объекты какого-то определенного размера, но при этом разумно оптимизированной по скорости. Понятно, что можно и самому написать, но зачем тратить время на велосипед? Всё что надо, чтобы делала malloc, free, и, по необходимости, лезла в физическую кучу за новым куском памяти. Буду благодарен за любую наводку.
Выше предлагали посмотреть unsynchronized_pool_resource.. Когда то давным давно делал подобную штуку для своих целей, отличия от unsynchronized_pool_resource примерно такие:
1. при освобождении памяти она возвращается в систему (в unsynchronized_pool_resource нет)
2. для освобождения нужно передать только указатель на блок памяти (в unsynchronized_pool_resource надо передать указатель + размер/выравниваение)
3. размер выделяемого блока можно задавать не только в рантайме, но и в compile time, это ускоряет выделение (в unsynchronized_pool_resource — только в рантайм)
4. некоторые арифметические моменты упразднены в силу структуры лайаута низлежащей памяти, что экономит некоторое количество вычислений (в unsynchronized_pool_resource такая арифметика делается в рантайме)
5. разбивка на пулы линейная а не геометрическая, это уменьшает перерасход памяти (в unsynchronized_pool_resource геометрическая)
6. (это скорее минус) адресное пространство под кучу выделяется целиком и сразу (иногда это приводит к проблемам с valgrind, с дампилкой gdb/gcore)
7. (это скорее минус) на 32бит-платформе не вполне эффективно, так как заранее забирает себе много адресного пространства и остальным не хватает. А вот на 64бит — в самый раз
8. (это скорее минус) в имеющемся виде вряд ли будет работать под виндой, там сейчас используется posix mmap/mptotect (но нет противопоказаний переписать на VirtualAlloc, есть работающий пример в другом проекте, если интересно)
АПИ тут https://github.com/vopl/heap3/blob/master/include/mm.hpp
в общем, эта штука очень хорошо себя показывает как однопочная куча для мелкогранулярных высокочастотных аллокаций.