Компания Miсrosoft открыла под лицензией MIT библиотеку mimalloc (https://github.com/microsoft/mimalloc) с реализаций системы распределения памяти, изначально созданной для runtime-компонентов языков Koka (https://github.com/koka-lang/koka) и Lean (https://github.com/leanprover/lean). Mimalloc адаптирован для использования в типовых приложениях без изменения их кода и может выступать в качестве прозрачной замены функции malloc. Поддерживается работа в Windows, macOS, Linux, BSD и других Unix-подобных системах.
Ключевой особенностью mimalloc является компактность реализации (менее, чем 3500 строк кода) и очень высокая производительность. В проведённых тестах (https://github.com/microsoft/mimalloc#performance) mimalloc обогнал по производительности все конкурирующие библиотеки распределения памяти, включая jemalloc (https://github.com/jemalloc/jemalloc), tcmalloc (https://github.com/gperftools/gperftools), snmalloc (https://github.com/microsoft/snmalloc), rpmalloc (https://github.com/rampantpixels/rpmalloc) и Hoard (https://github.com/emeryberger/Hoard).
Для оценки производительности использован набор уже существующих типовых тестов (https://github.com/daanx/mimalloc-bench) В некоторых тестах mimalloc опережает другие системы в разы, например, в тесте миграции объектов между разными потоками mimalloc оказался быстрее tcmalloc и jemalloc более чем в 2.5 раза. При этом в большинстве тестов также наблюдается более низкое потребления памяти, в некоторых ситуациях расход памяти удаётся снизить на 25%.
Высокая производительность достигается в основном за счёт применения сегментирования списка свободных блоков (free list sharding). Вместо одного большого списка в mimalloc применяется разделение на серию более мелких списков, каждый из которых привязывается к странице памяти. Подобный подход снижает фрагментацию и повышает локализацию данных в памяти. Под страницей памяти понимается сгруппированный набор близких по размеру блоков. На 64-разрядных системах размер страницы обычно составляет 64 КБ. В случае, если в странице не остаётся занятых блоков, она полностью освобождается с возвращением памяти операционной системе, что позволяет снизить затраты памяти и фрагментацию в длительно работающих программах.
Библиотеку можно подключить на этапе связывания или подгрузить для уже собранной программы ("LD_PRELOAD=/usr/bin/libmimalloc.so myprogram"). В библиотеке также предоставляется API (https://microsoft.github.io/mimalloc/group__extended.html) для интеграции функциональности в runtime и тонкого управления поведением, например, для подключения обработчиков отложенного освобождения памяти и монотонного увеличения счётчиков ссылок. Имеется возможность создания и использования в приложении нескольких "куч" (heap) для распределения по разным областям памяти. В том числе возможно освобождение кучи целиком, без перебора и отдельного освобождения размещённых в ней объектов.Предусмотрена возможность сборки библиотеки в безопасном режиме, в котором на границе блоков осуществляется подстановка специальных проверочных страниц памяти (guard-page), а также используется рандомизация распределения блоков и шифрование списков освобождаемых блоков. Подобные меры позволяют блокировать большинство типовых техник эксплуатации переполнений буферов в куче. При включение безопасного режима производительность снижается примерно на 3%.
Из особенностей mimalloc также отмечается не подверженность проблемам с раздутием при большой фрагментации. В наихудшем сценарии потребление памяти возрастает на 0.2% для метаданных и может достигать 16.7% для распределяемой памяти. Для исключения конфликтов при доступе к ресурсам в mimalloc применяются только атомарные операции.
URL: https://news.ycombinator.com/item?id=20249743
Новость: https://www.opennet.me/opennews/art.shtml?num=50939
Вот кто делает истинный вклад в Open Source! Microsoft пришла — порядок навела!
Ну это по сравнению с другими их поделками ( не в счет xbox и exchange )Торт, главное, что б в их "прозраности" никаких костылей не торчало, а выглядит оч даже съедобно (судя по анонсу )
Microsoft - просто шильдик. Очевидно же что в компании есть много очень разных команд. Разработки, нужные, но не продающиеся, мс выводит в опенсорс, разумно же.
Как это проживает в сравнении с другими быстрыми менеджерами памяти? Сравнивать с самыми тормозными - это конечно шик...
> не в счет xbox и exchangeВ счет в первую очередь
Там заточка по конкретный HW + остутвие необходиомсти залагивать ОС: игры либо совместимы, либо нет - и иди покупай новую приставку, даже для типов игр которые могут тянуть и Dendy.По сути схожее успешно сделали и с "PC"(в кавычках, уже давно) - MS осями(да и линуксами...) + руками авторов ПО под них, но пока не полностью же: повсеместные "Ситемные требования" - минимум самой предпоследней ОСи, Windows 10. Но, что само говорит что уже оч.близко подобрались.
> выглядит оч даже съедобно (судя по анонсу )Так же было с форматом docX, xlsx файлов Офис.
Оказалось - сами в своей реализации отошли от своего стандарта.
Поптыка работать со Скайп Фор Бизнес (это совершенно отдельная от "гражданского" Скайп реализация для Скайп+Аутлук, замена MS-Линка), использование MS Teams (платная замена Скайпа; Линк, Скайп Фор Бизнес больше не развивается, заменено платным сервисом), Аутлука 365, Офиса 365 под Вин 10, Офиса 2010 с Линком и т.д., опыт автоматизации развёртки Студио, работа при обновлениях со старшими администраторами MS продуктов на предприятии - всё это внушает бооооооольшие опасения продуктов жизнедеятельности Microsoft.
Линукс десктоп 10+ лет вёл себя гораздо более дружественней. При всей гибкости и обилии замен и новья под Л. всегда можно было решить вопрос. С Мелкомягкими - не было такого.
Короче, Вы смотрите по делам, а не по пресс-релизам. :)))
Microsoft? Вклад? Да этому алгоритму сто лет в обед, в паскалях стандартный аллокатор так работает.
вы какой паскаль имеете в виду? их очень много.. разных
Не могу простить за нокию
в смысле что не дали той самостоятельно обанкротиться?
Хороший такой "банкрот" через прихватизацию патентов и запрет заниматься телефонками на несколько лет.
> Хороший такой "банкрот" через прихватизацию патентов и запрет заниматься телефонками на
> несколько лет.дружище, когда я покупаю чей-то идущий на дно бизнес - я его таки покупаю, а не создаю его клон с тем же самым названием, и, разумеется, приму меры, чтобы он не смог и на елку влезть, и жопу не уколоть - и патенты придется отдавать, и клиентуру, и без возможности отыграть назад, да, денежки платят не за красивые глазки.
А вот когда мне его продают (и речь не о стартапе, который для того и брали, а о давно существующей и якобы успешной компании) - это говорит ровно о том, что владельцы бизнеса по уши в долгах, понятия не имеют, что со всем этим делать, и продаться подороже - единственный их шанс вылезти из долговой ямы. Надеюсь, они теперь счастливы, и их бизнесу по network management outsource ничто не угрожает (если что - мы такое - не купим, не надейтесь)
Что нам эта покупка принесла одни убытки - это уже наши ошибки. Китайцы вон вполне со (теперь) своим алкателем счастливы. Впрочем, с HERE бингу была определенная польза.
> ...это говорит ровно о том, что владельцы бизнеса по уши в долгах,...Ни о чём это не говорит, особенно, учитывая, что директором работал инсайдер от Микрософт.
к тому моменту, как мы его сделали директором - именно что ВСЕ полимеры были проcpаны.
Его и призвали-то только потому, что других дураков руководить обреченным бизнесом не нашлось.а этот хотя бы сумел выгодно продать, и при этом аккуратно уволить все бесполезное кубло, жравшее зарплаты и нихрена уже приносящего доходы сделать неспособное
к тому моменту эппл уже своровала десяток патентов нокии.
>Не могу простить за нокию+1 Lumia 820 была разочарованием, причем не по железу - именно что по Windows Phone.
M$ EEE! Запомни и вбей себе в мозг.
Судя по графикам, у них там монохромные мониторы, что ли?
А вы бы предпочли радугу из цветов для однотипных данных ?
Так как системы во всех тестах идут в одном и том же порядке (и их количество везде одинаково), то в принципе можно вообще одним цветом показывать.
Так же, так как mimalloc вообще(без всяких апелляций ;) самая ЛУЧШАЯ система, остальные можно (и даже нужно) не показывать, что бы у аудитории не оставалось никаких сомнений, что это ОНА единственная и самая совершенная система! ;)
А так чо, удобно же ;)
Можно было столбики, соответствующие разным распределителям памяти, покрасить каждый в свой цвет.
> Судя по графикам, у них там монохромные мониторы, что ли?oocalc'ом рисовали - не хватило бюджета на ms office.
Короче говоря, они забили болт на экономию памяти и получили прирост производительности. Не сказать, чтобы результат был неожиданным.
что>При этом в большинстве тестов также наблюдается более низкое потребления памяти, в некоторых ситуациях расход памяти удаётся снизить на 25%
А ты пойди по ссылке и посмотри второй график, который в новость почему-то не добавили. "В некоторых случаях" © расход памяти возрос на 300% (в одном отдельно взятом тесте, но не забываем, что они все синтетические).
Ты про "note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs"?
Ну объясни, почему тогда с glibc он столько не жрёт.
> Ну объясни, почему тогда с glibc он столько не жрёт.Потому что с glibc тесты работают медленнее.
То есть
> они забили болт на экономию памяти и получили прирост производительностичто и требовалось доказать.
Нет. Если ты сравнишь графики производительности и расхода памяти на тесте xmalloc-testN, то ты увидишь обратную корреляцию между ними даже на глаз. Если тест на расход памяти даёт такую корреляцию, то это вопрос к тесту, который меряя расход памяти, на самом деле меряет скорость.
> в большинстве тестов также наблюдается более низкое потребления памяти,
> в некоторых ситуациях расход памяти удаётся снизить на 25%.
Я сам не являюсь поклонником упомянутой в новости компании. Конечно, хотелось бы отпустить пару язвительных шуток про скорость, что нужно добавить в их логотип черточки с Формулы-1 и что "К" в их логотипе Microsoft обозначает компактность, но если перейти по ссылке - действительно выдающийся результат. Не поленился и сложил src/*.c + include/*.h = 6439 LOC (с комментариями и пустыми)
Скорость выше, потребление памяти ниже, даже опережает jemalloc, который в прошлогодних тестах был уверенным победителем. //ithare.com/testing-memory-allocators-ptmalloc2-tcmalloc-hoard-jemalloc-while-trying-to-simulate-real-world-loads/
Осталось дождаться независимых тестов и можно поздравить.
При текущей стоимости памяти даже увеличение на 300% в угоду скорости работы не является критичным. КЕды вон жрут 2-4 гига оперативки и никто не жалуется.
вы кеды здорового человека как давно видели?
Если кеды из коробки больны, то в массе это будут кеды больного человека. Исключения погоды не делают.
Из коробки могут быть только люди больны. Кеды уже давным давно вылечили.
Ты кеды у себя в винде поставил?
Заслуга компании в том, что она оплатила эту работу, а потом ее открыла. А делать это могли любые аутсорсеры, не имеющие к М никакого отношения.
Заслуга компании здесь весьма сомнительна.
Выложить проект размером с университетскую курсовую, такого же качества и выдавать это как нечто революционное, это, как мне кажется, немного некрасиво.
Для компании уровня МС "оплатила" такую работу я просто промолчу.
Первые независимые тесты подтверждают мои слова //github.com/microsoft/mimalloc/issues/11
Сильно сомневаюсь, что сама компания будет использовать это в своих продуктах.
Ну да, проекты же только размером меряются. А issue... Ну нашли неудачный кейс - большие аллокации вместе с особенностями линуксового mmap. И что?
Если проект маленький, а корпорация сильная, то, по малости проекта, не должно бы быть в нём "неудачных кейсов". Или сразу возникает сомнение в продукте.
Я понимаю, плевать на содержание, главное объем.
Вы явно давно не видели студенческих курсовых.
Если бы у всех программистов были бы хотя бы такие курсовые, то вряд ли мы сейчас жили бы в мире электронов и прочих гтк
Надо бы теперь на чём-то реальном проверить:
LD_PRELOAD=/usr/bin/libmimalloc.so firefox
А можно:
export LD_PRELOAD=/usr/bin/libmimalloc.so
прописать в /etc/profile?
Здесь была шутка про ~/.config.sys :)
И ~/.wine/emm386.exe
Уже проверили на запросах к базе.
jmalloc оказался в 2 раза быстрее.//github.com/microsoft/mimalloc/issues/11
sudo apt install libmimalloc2.0
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libmimalloc.so.2 firefoxи лиса падает :-/
Electron от майкрософта - вот будущее свободного програмного обеспечения.
> Electron от майкрософта - вот будущее свободного програмного обеспечения.агащасс. Мы для чего с гуглем-то договаривались? Элехтрон может быть только один!
https://github.com/microsoft/mimalloc/issues/11
вроде даже как обещали починить, но типа намекают, что оно немного не под такое использование было рассчитанно.
> оно немного не под такое использование было рассчитанно.
> (being build for many short lived small allocations :-) )Так, ясно, одной библиотекой, оказывается, принципиально не обойтись. Значит,
LD_PRELOAD=/usr/bin/libmalloc_wrapper.so
malloc_wrapper.c:
if (foo) {
mimalloc();
} else if (boo) {
jemalloc();...
} else {
glibc_malloc();
}
разумеется, не обойтись - иначе зачем, по-твоему, jemalloc существует столько лет, но в glibc - используют совершенно другой?Но if(foo) может выполнять только сама программа - разработчик которой знает или хотя бы может пытаться угадать, как именно память будет использована. И выбирать себе аллокатор под конкретную задачу.
Внутри вызова malloc() ты уже никак это не выяснишь.
> Внутри вызова malloc() ты уже никак это не выяснишь.Тогда надо бы в POSIX добавить аналог fadvise только для malloc. И, похоже, уже давно надо было бы.
это ж софт переписывать, весь.а тут можно обойтись LD_PRELOAD - по крайней мере, иногда.
> намекают, что оно немного не под такое использование было рассчитанно.То ли ещё будет, когда кто-нибудь решит эффективнсоть realloc() проверить…
>Danila Kutenin
>HSE FCS studentк вопросу о курсовых
А, так вот откуда бросившийся в глаза ещё из заголовка префикс "mima" :]
>/usr/bin/libmimalloc.soУзнаю Венду, хоть тут конкретно и .so
В новости же
/usr/lib/libmimalloc.so
Сатья наживку заглотили можешь подсекать.
От Майкрососфт нам ничего не нужно.
Нам это тебе и твоему воображаемому другу?
MS EEE тебе в щель.
Микрософт уже напоминает студентку 4 курса.
https://anekdot.livejournal.com/2694119.html
По накопленным деньгам? )
Что там с безопасТностью и сторонними каналами?
Hoard устарел в пользу https://github.com/plasma-umass/Mesh
Выделение и освобождение памяти происходит настолько редко, по сравнению с доступом к ней, что библиотека не даст прироста в реальных приложениях
Даже усугубит работу в многопоточных приложения. Аллокатор будет тратить большую часть работы.
Бойтесь нанайцев дары приносящих
Ты проверял? Ну, то есть, твои теоретические выводы полагаются на то, что выделение/освобождение памяти примерно одинаково с доступом по скорости. Но это резко совсем не так. Выделение/освобождение гораздо-гораздо медленнее. Поэтому было бы интересно посмотреть на бенчмарки.
Да, проверял, свободен
> Да, проверял, свободенСсылку?
>> Да, проверял, свободен
> Ссылку?да что вы, у нас джентльменам верят на слово!
(впрочем, да, то ж- джентльменам, а тут явно персонаж которому "но вы не стесняйтесь и тоже заходите")
В школе что-ли? Любые операции даже со строками - это постоянное выделение/освобождение памяти.
Вы ещё из тех, кто пишет программы, выделяя на старте память одним куском и в конце её освобождая? В большинстве современных приложений (например, тот же жеес на фронтенде) память частенько даже в цикле выделяется. Погуглите скриншоты любых мемори профайлеров - там ряды аллокаций просто сплошные без промежутков. Вот как раз в таких задачах очень может пригодиться.
Что значит "еще из тех"?)
Если вы современный смузихлеб, пишущий на электроне приложения жрущие по 16 Гб памяти чтобы отобразить чатик и выделяете по мегабайту в цикле - что ж, я рад, что всегда найдется работа для настоящих профессионалов, у которых на счету каждый байт. И да, даже однократный вызов динамической аллокации - полная жесть, и уважающий себя программист никогда так делать не будет.
микрософт туда уже инкрустировал азуре или еще нет?
К слову о крурсовых.... а старые преподы до сих пор просят запилить дефагментацию кучи? Типа указатель на указатель на указатель на массив указателей. Мы как-то лет 15 назад запилили.... и даже что-то со своим маллоком собрали. Даже работало.
А почему бы и нет? Может кто Танненбаума не читал :-)
Всю жизнь думал, что память выделяет ядро, а malloc это просто системный вызов. И тут такое откровение.
malloc() не системный вызов, а библиотечный. Системные вызовы это brk()/sbrk()/mmap()/munmap().
386 уже давно на свалке, как и книга K&R.http://www.opennet.me/man.shtml?topic=malloc&category=3&russ...
Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).
> И тут такое откровение.типикал опеннет юзер
и ничего, что исходник malloc в книжке Ритчи опубликован. Ему ведь и в голову не пришло ее читать.
Где в договоре написано, что пользователи опеннета обязаны прочитать книгу ритчи?
Пользовательи опеннет обязаны:
1. при первом упоминании microsoft хотя бы раз отписаться про EEE - выполнено.
2. при первом упоминании чего угодно графического хотя бы раз отписаться про Electron - выполнено
3. Уважать только Си и баш-скрипты инициализации - в процессе
Радио "радонеж" забыли.
ОС просто гарантирует, что память одного приложения физически (в планке ОЗУ) не будет налазить на память другого приложения. То есть ОС выделяет ВИРТУАЛЬНОЕ адресное пространство, а приложение управляет виртуальной памятью как хочет.
теперь ждём, когда это появится в Reactos
Строго говоря не гарантирует, но пытается засегфолтить все бинарники, пытающиеся залезть за пределы своей песочницы.
А это точно проект мс, а не Xiaomi? Название слишком характерное