| 1.1, нах. (?), 22:16, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
Фейсбук за все берется смело... боюсь получится как с memcache.
| | |
| 1.3, Ivan_83 (ok), 22:33, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
 Ни одной буквы о том как изменилась производительность.
Подозреваю что там никаких улучшений нет уже лет 10, а автор перевёл его в архив потому что делать там больше нечего, всё и так прекрано работает.
| | |
| |
| 2.5, Аноним (5), 22:41, 18/09/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что mimalloc быстрее и эффективнее, конкурировать с ним пустое дело. Сабж позволяет решать специфические задачи специфического оборудования. В кластерах, да. Если рассматривать сабж на примере жырнолиса, можно ему зажать пиковую память, но тогда тормозит очень сильно. Почему каждые 3 секунды выделяет и удаляет по гигабайту памяти на твиче, никто так и не объяснил. Иногда просто начинает течь. Если поменять на mimalloc (требует перекомпиляция), не течёт.
| | |
| |
| 3.9, Аноним (9), 23:47, 18/09/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Потому что mimalloc быстрее и эффективнее
Только память освобождать не умеет, лол.
| | |
| |
| 4.42, Аноним (42), 13:12, 19/09/2026 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> память освобождать не умеет
Прям как у раста - ныне это естественное поведение.
| | |
|
| 3.12, вымя (?), 00:20, 19/09/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
> mimalloc
> конкурировать с ним пустое дело
...по части багов. В одном только solvespace с ним постоянная возня и необходимость прибивать конкретные версии:
> Confirmed that going back to the vendored mimalloc fixes it
> This is fixed in v2.2.4, but we unfortunately can't use it due to another issue (microsoft/mimalloc#1124), so we have to downgrade for now until it is fixed.
> mimalloc has been the least reliable dependency | | |
| |
| 4.58, Аноним (58), 19:13, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> В одном только solvespace с ним постоянная возня
А им-то зачем нестандартный malloc, для wasm что ли?
Как тогда всё остальное emscripten собирает, так же через жопу?
| | |
|
| 3.13, Ivan_83 (ok), 00:24, 19/09/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
Без понятия как там быстрее или нет mimalloc, я не замечал чтобы у меня что либо тормозило.
Нормально написанный софт аллокатор лишний раз не дёргает.
В случае браузера - возможно, там же джава внутри может какой угодно какакод запускать.
Лису я тоже память на уровне системы ограничил, но так чтобы он меня часто не беспокоил своим перееданием и тормозами.
Твич не юзал, вероятно какахокодеры на жабаскрипте там что то учудили.
| | |
| |
| 4.18, Сладкая булочка (?), 01:53, 19/09/2026 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> вероятно какахокодеры на жабаскрипте там что то учудили
Проблемы негров ширифа не волнуют или зачем в языке с гц думать об аллокациях? Вот они и не думают.
| | |
|
| 3.14, Ivan_83 (ok), 00:29, 19/09/2026 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Я как бы целом имел ввиду что аллокатору развиватся особо некуда.
Один раз выбрали стратегию, выбрали свой баланс и всё.
За все годы разве что huge pages отрасли и ещё очень по мелочи всякие флаги для mmap(), и sbrk() выкинули. На этом всё развитие и кончается. Раз в 5 лет только поглядывать что по мелочи подкорректировать под текущие стандарты языка С, и специфики системы.
Если кто то там до сих пор каждую неделю или месяц релизит свой аллокатор - я бы от такого держался по дальше - люди явно эксперементируют и там процесс ради процесса а не для результата.
| | |
|
| 2.15, вымя (?), 00:31, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Ни одной буквы о том как изменилась производительность.
> This release contains over 160 commits, focusing on the technical debts cleaning including refactorings, bug fixes, test coverage improvement, and option cleanups.
Все ускорения они ещё в 5.3 обещали. Но смысла никакого верить красивым чиселкам нет, надо тестировать каждое приложение отдельно, потому что паттерн выделения памяти у всех разный. Бывает даже так:
> Using jemalloc as Ruby’s default is a bit problematic. There was a heated discussion in the Ruby bug tracker about this, but in the end no decision was made. The main issue raised is the fact that memory usage only reduces when using jemalloc 3; memory usage is still high when using jemalloc 5. Nobody knows why, so that makes the choice of defaulting to jemalloc very dodgy. | | |
| |
| |
| 4.22, Аноним (22), 05:55, 19/09/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тухло с этим. Пока самый лучший результат у Fable 5.1 с оценкой 7% при попытке написать бинарник в машинных кодах без посредника в виде языков программирования. Но начало положено, авось лет через 5 будет что-то внятное (если государства и корпорасты не придушат ИИ).
| | |
|
|
| 2.21, Аноним (22), 05:52, 19/09/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Ни одной буквы о том как изменилась производительность.
Там просто нечего улучшать при всём желании
| | |
|
| 1.8, Аноним (8), 23:33, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Ненужно. Если требуется специальное управление памятью, то сам напишу. Функциями ос никто ещё пользоваться не запрещал, не все правда про них знают почему-то.
| | |
| |
| 2.19, Абра (?), 04:51, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
А после таких деятелей месяцами ловим случайные мютексы, потому что не научились читать документацию до конца...
| | |
| |
| 3.41, Аноним (41), 13:08, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я понимаю что ты не настоящий сварщик, но почитай немного про кеш, выравнивание, доступ к памяти и тп и удивись насколько можно убыстрить программу просто грамотно работая с памятью.
| | |
| |
| 4.44, Аноним (22), 13:17, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> убыстрить программу
Не стоит оно того, ради "убыстрения" на 0.01%. Лучше просто купить новое железо.
| | |
| |
| |
| 6.60, Аноним (22), 23:19, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Здесь дело не в консьюмеризме, а в разумном размене времени/денег. В реальности ВСЕГДА выгоднее апгрейднуть железо, чтобы получить РЕАЛЬНЫЙ прирост производительности, чем заниматься экономией на спичках ради сомнительного прироста в бенчмарках.
| | |
|
| |
| 6.49, Аноним (49), 15:33, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
 > Цифры у тебя конечно же высосаны.
То ли дело "цифры" в "насколько", ога. Кстати, очередной (к)експерт не в курсе, что malloc в современных либах обычно отдает уже выровненную память (а если нужно, то можно и запросить: valloc, posix_memalloc, aligned_alloc) ...
| | |
| |
| 7.52, Аноним (8), 17:04, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Дурачок ты, ии тебе ответ подсказал, но смысла ты не понимаешь того что написал
| | |
|
|
|
|
|
|
| 1.24, DEF (?), 08:01, 19/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– |
Смеялся. C настолько крут, что ему нужна аж целая отдельная библиотека для выделения памяти.
| | |
| |
| 2.29, Аноним (29), 09:22, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Любителя Rust видно из далека. Вера в безопасную работу с памятью есть, а знаний работы ОС нет.
| | |
| |
| 3.50, DEF (?), 16:28, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
У тебя есть знания ОС? Покажи свои коммиты в проект любой ОС.
| | |
| |
| 4.53, Аноним (29), 17:20, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>У тебя есть знания ОС?
Есть.
>Покажи свои коммиты в проект любой ОС.
Не покажу, не хочу спойлерить.
| | |
|
|
| 2.31, Ivan_83 (ok), 09:39, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Да как бы можешь в виде .h файла заинлайнить, тебя же никто не заставляет.
Но в целом, судя по коменту, вы похоже из тех кто думает что электричество из розетки берётся а память язык магическим образом у ОС забирает и программе отдаёт %)
| | |
| |
| 3.51, DEF (?), 16:37, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Зачем я должен инлайнить лишний .h файл какой-то либы, которая не делает ничего, кроме как выделяет память? Выделение памяти - это стандартная, вшитая в язык операция. Если C не способен нормально выделить память своими собственными средствами без посторонних либ - его место на свалке истории.
| | |
| |
| 4.55, Аноним (29), 17:31, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Хотя бы нейронку спросили бы, чем писать такое. ОС выделяет страницу памяти, с которой уже работает аллокатор стандартной библиотеки, когда программист вызывает malloc.
>Выделение памяти - это стандартная, вшитая в язык операция.
Попробуйте в Rust флаг no_std, вы будете в шоке.
| | |
|
|
| 2.57, Сладкая булочка (?), 18:49, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> C настолько крут, что ему нужна аж целая отдельная библиотека для выделения памяти.
...которую используют в расте
| | |
|
| 1.25, Аноним (25), 09:06, 19/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните мне простому зачем нужная такая библиотека, если такой механизм предоставляется самой ОС через системные вызовы? Он что типо в обход системных вызовов работает?
| | |
| |
| 2.28, Аноним (29), 09:20, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Это функционал библиотеки Си, а ОС представляет только функционал POSIX по типу mmap и munmap.
| | |
| 2.32, Ivan_83 (ok), 09:41, 19/09/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
И что же предоставляется самой ОС?
sbrk задепрекейтили, остался только mmap(), минимальная аллокация = PAGE_SIZE = 4кб на AMD64.
Без аллокатора на прямых mmap() мало того что память будет излишне расходоватся так ещё и в сисколы упрётесь в некоторых задачах.
| | |
| 2.39, Фембойчик (?), 12:18, 19/09/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тоже нефига не понял, зачем, если в стандартной библиотеке уже все есть. Правда я не сишник и вообще не погромист.
| | |
| |
| 3.46, Аноним (47), 14:32, 19/09/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Потому что ты не знаешь как это всё работает, поэтому и не понял.
| | |
|
|
| |
| 2.33, Ivan_83 (ok), 09:42, 19/09/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
А не получится, там слишком низкоуровнево и слишком хаки местами.
| | |
|
|
