forum.opennet.ru - "Доступна библиотека управления памятью jemalloc 5.3.1" (17)

"Доступна библиотека управления памятью jemalloc 5.3.1"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
Сообщение от opennews (ok), 14-Апр-26, 15:06
Спустя 4 года после публикации прошлого обновления доступен релиз библиотеки управления памятью jemalloc 5.3.1, предлагающей альтернативную реализацию функций malloc, оптимизированную для снижения фрагментации и работы на многопроцессорных системах. Для решения проблем с блокировками на многоядерных системах в jemalloc для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков... Подробнее: https://www.opennet.me/opennews/art.shtml?num=65201
Ответить \| Правка \| Cообщить модератору

Оглавление

Я бы даже не стал шутить про отставить разврат - закопать стюардессу отставить, Жироватт (ok), 15:06 , 14-Апр-26, (1) –1

для каждого ядра CPU используется своя изолированная область распределения памят, Аноним (2), 15:34 , 14-Апр-26, (2)

Скрыто модератором, Жироватт (ok), 15:50 , 14-Апр-26, (4) +1
А как же общий буфер, общее адресное пространство процесса , Аноним (5), 16:37 , 14-Апр-26, (5) –1

Общее адресное пространство никуда не делось, но в многопоточной среде эффективн, Аноним (8), 16:46 , 14-Апр-26, (8)

это понятно Значит ли это что есть изолированная общая область памяти в дополне, Аноним (5), 17:01 , 14-Апр-26, (10)

Нет Адресное пространство общее Но мы внутри процесса принимаем конвенцию, что , Аноним (18), 20:18 , 14-Апр-26, (18)
Там нет и не может быть ничего изолированного Память выделенная на thread-loc, Аноним (8), 20:26 , 14-Апр-26, (19)

Меньшая фрагментация за счет изолированных областей А внутри области такая же д, Аноним (5), 16:38 , 14-Апр-26, (6)

Не фрагментация, а lock contention , Аноним (8), 16:46 , 14-Апр-26, (9)

Прожорливый поток может залочить себе всю память , Аноним (5), 17:03 , 14-Апр-26, (11)

Скрыто модератором, Аноним (8), 20:16 , 14-Апр-26, (17)

Он один из самых эффективных , Аноним (8), 16:44 , 14-Апр-26, (7) +2
Это не тут спрашивать надо, это на https engineering fb com спрашивать надо , Аноним (14), 17:50 , 14-Апр-26, (14)

Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl Сабж или в, Аноним (12), 17:07 , 14-Апр-26, (12)

Вместо musl Glibc , Аноним (15), 17:51 , 14-Апр-26, (15) –1
странный вопрос, есть стандарт , который по сути есть компромис среди множества, Аноним (16), 18:38 , 14-Апр-26, (16)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Жироватт (ok), 14-Апр-26, 15:06 –1 +/–

Я бы даже не стал шутить про "отставить разврат - закопать стюардессу! отставить разврат - откопать стюардессу", но реально, в чем профит использовать конкретно этот аллокатор?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #7, #14

2. Сообщение от Аноним (2), 14-Апр-26, 15:34 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4, #5, #6

4. Сообщение от Жироватт (ok), 14-Апр-26, 15:50 Скрыто ботом-модератором +1 +/–

Ну, в копипаст и я могу.
А реально?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Аноним (5), 14-Апр-26, 16:37 –1 +/–

>своя изолированная область
А как же общий буфер, общее адресное пространство процесса?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

6. Сообщение от Аноним (5), 14-Апр-26, 16:38 +/–

Меньшая фрагментация за счет изолированных областей? А внутри области такая же дефрагментация?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

7. Сообщение от Аноним (8), 14-Апр-26, 16:44 +2 +/–

> в чем профит использовать конкретно этот аллокатор?
Он один из самых эффективных.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

8. Сообщение от Аноним (8), 14-Апр-26, 16:46 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #10

9. Сообщение от Аноним (8), 14-Апр-26, 16:46 +/–

> Меньшая фрагментация за счет изолированных областей?
Не фрагментация, а lock contention.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

10. Сообщение от Аноним (5), 14-Апр-26, 17:01 +/–

>thread-local
это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18, #19

11. Сообщение от Аноним (5), 14-Апр-26, 17:03 +/–

Прожорливый поток может залочить себе всю память?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #17

12. Сообщение от Аноним (12), 14-Апр-26, 17:07 +/–

Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #16

14. Сообщение от Аноним (14), 14-Апр-26, 17:50 +/–

> в чем профит использовать конкретно этот аллокатор?
> месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре
Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

15. Сообщение от Аноним (15), 14-Апр-26, 17:51 –1 +/–

> вместе с musl
* Вместо musl.
Glibc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 14-Апр-26, 18:38 +/–

странный вопрос, есть "стандарт", который по сути есть компромис среди множества архитектур и альтернатив аля glibc, то есть работает не идеально, но приемлемо, чего достаточно для большенства задач, но если вам не достаточно, то надо отталкиваться от архитектуры и особенностей проекта, можно попробовать для начала и сабж, но musl скорее про эндебер и там будет скорее хуже, а значит писать свое под свою задачу, хотя, если проект один, проще это решать на уровне проекта чтобы не плодить сущности. Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь, но один раз его пройдя можно попутно решить все "проблемы", в том числе с выходом за границы буфера, юз-афтер-фри, и прочие за которые хейтят сечас си, и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

17. Сообщение от Аноним (8), 14-Апр-26, 20:16 Скрыто ботом-модератором +/–

Нет, потоки будут бороться за доступ к shared структурам аллокатора.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

18. Сообщение от Аноним (18), 14-Апр-26, 20:18 +/–

Нет.
Адресное пространство общее. Но мы внутри процесса принимаем конвенцию, что для каждого потока есть выделенная область памяти, из которой он аллоцирует. Ядро и MMU об этом "ничего не знают", адресное пространство общее, просто процесс, использующий данный аллокатор, так работает со своей памятью.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

19. Сообщение от Аноним (8), 14-Апр-26, 20:26 +/–

Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах.
Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Жироватт (ok), 14-Апр-26, 15:06	–1 +/–
Я бы даже не стал шутить про "отставить разврат - закопать стюардессу! отставить разврат - откопать стюардессу", но реально, в чем профит использовать конкретно этот аллокатор?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2, #7, #14

2. Сообщение от Аноним (2), 14-Апр-26, 15:34	+/–
для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #4, #5, #6

4. Сообщение от Жироватт (ok), 14-Апр-26, 15:50 Скрыто ботом-модератором	+1 +/–
Ну, в копипаст и я могу. А реально?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

5. Сообщение от Аноним (5), 14-Апр-26, 16:37	–1 +/–
>своя изолированная область А как же общий буфер, общее адресное пространство процесса?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #8

6. Сообщение от Аноним (5), 14-Апр-26, 16:38	+/–
Меньшая фрагментация за счет изолированных областей? А внутри области такая же дефрагментация?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #9

7. Сообщение от Аноним (8), 14-Апр-26, 16:44	+2 +/–
> в чем профит использовать конкретно этот аллокатор? Он один из самых эффективных.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

8. Сообщение от Аноним (8), 14-Апр-26, 16:46	+/–
Общее адресное пространство никуда не делось, но в многопоточной среде эффективнее выделять из thread-local арен.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #10

9. Сообщение от Аноним (8), 14-Апр-26, 16:46	+/–
> Меньшая фрагментация за счет изолированных областей? Не фрагментация, а lock contention.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #11

10. Сообщение от Аноним (5), 14-Апр-26, 17:01	+/–
>thread-local это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #18, #19

11. Сообщение от Аноним (5), 14-Апр-26, 17:03	+/–
Прожорливый поток может залочить себе всю память?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #17

12. Сообщение от Аноним (12), 14-Апр-26, 17:07	+/–
Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #15, #16

14. Сообщение от Аноним (14), 14-Апр-26, 17:50	+/–
> в чем профит использовать конкретно этот аллокатор? > месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

15. Сообщение от Аноним (15), 14-Апр-26, 17:51	–1 +/–
> вместе с musl * Вместо musl. Glibc.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 14-Апр-26, 18:38	+/–
странный вопрос, есть "стандарт", который по сути есть компромис среди множества архитектур и альтернатив аля glibc, то есть работает не идеально, но приемлемо, чего достаточно для большенства задач, но если вам не достаточно, то надо отталкиваться от архитектуры и особенностей проекта, можно попробовать для начала и сабж, но musl скорее про эндебер и там будет скорее хуже, а значит писать свое под свою задачу, хотя, если проект один, проще это решать на уровне проекта чтобы не плодить сущности. Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь, но один раз его пройдя можно попутно решить все "проблемы", в том числе с выходом за границы буфера, юз-афтер-фри, и прочие за которые хейтят сечас си, и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

17. Сообщение от Аноним (8), 14-Апр-26, 20:16 Скрыто ботом-модератором	+/–
Нет, потоки будут бороться за доступ к shared структурам аллокатора.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

18. Сообщение от Аноним (18), 14-Апр-26, 20:18	+/–
Нет. Адресное пространство общее. Но мы внутри процесса принимаем конвенцию, что для каждого потока есть выделенная область памяти, из которой он аллоцирует. Ядро и MMU об этом "ничего не знают", адресное пространство общее, просто процесс, использующий данный аллокатор, так работает со своей памятью.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

19. Сообщение от Аноним (8), 14-Апр-26, 20:26	+/–
Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах. Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10