The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Miсrosoft открыл код системы распределения памяти mimalloc

23.06.2019 09:15

Компания Miсrosoft открыла под лицензией MIT библиотеку mimalloc с реализаций системы распределения памяти, изначально созданной для runtime-компонентов языков Koka и Lean. Mimalloc адаптирован для использования в типовых приложениях без изменения их кода и может выступать в качестве прозрачной замены функции malloc. Поддерживается работа в Windows, macOS, Linux, BSD и других Unix-подобных системах.

Ключевой особенностью mimalloc является компактность реализации (менее, чем 3500 строк кода) и очень высокая производительность. В проведённых тестах mimalloc обогнал по производительности все конкурирующие библиотеки распределения памяти, включая jemalloc, tcmalloc, snmalloc, rpmalloc и Hoard.

Для оценки производительности использован набор уже существующих типовых тестов В некоторых тестах mimalloc опережает другие системы в разы, например, в тесте миграции объектов между разными потоками mimalloc оказался быстрее tcmalloc и jemalloc более чем в 2.5 раза. При этом в большинстве тестов также наблюдается более низкое потребления памяти, в некоторых ситуациях расход памяти удаётся снизить на 25%.

Высокая производительность достигается в основном за счёт применения сегментирования списка свободных блоков (free list sharding). Вместо одного большого списка в mimalloc применяется разделение на серию более мелких списков, каждый из которых привязывается к странице памяти. Подобный подход снижает фрагментацию и повышает локализацию данных в памяти. Под страницей памяти понимается сгруппированный набор близких по размеру блоков. На 64-разрядных системах размер страницы обычно составляет 64 КБ. В случае, если в странице не остаётся занятых блоков, она полностью освобождается с возвращением памяти операционной системе, что позволяет снизить затраты памяти и фрагментацию в длительно работающих программах.

Библиотеку можно подключить на этапе связывания или подгрузить для уже собранной программы ("LD_PRELOAD=/usr/lib/libmimalloc.so myprogram"). В библиотеке также предоставляется API для интеграции функциональности в runtime и тонкого управления поведением, например, для подключения обработчиков отложенного освобождения памяти и монотонного увеличения счётчиков ссылок. Имеется возможность создания и использования в приложении нескольких "куч" (heap) для распределения по разным областям памяти. В том числе возможно освобождение кучи целиком, без перебора и отдельного освобождения размещённых в ней объектов.

Предусмотрена возможность сборки библиотеки в безопасном режиме, в котором на границе блоков осуществляется подстановка специальных проверочных страниц памяти (guard-page), а также используется рандомизация распределения блоков и шифрование списков освобождаемых блоков. Подобные меры позволяют блокировать большинство типовых техник эксплуатации переполнений буферов в куче. При включении безопасного режима производительность снижается примерно на 3%.

Из особенностей mimalloc также отмечается неподверженность проблемам с раздутием при большой фрагментации. В наихудшем сценарии потребление памяти возрастает на 0.2% для метаданных и может достигать 16.7% для распределяемой памяти. Для исключения конфликтов при доступе к ресурсам в mimalloc применяются только атомарные операции.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Менеджер распределения памяти jemalloc выпущен в виде отдельной библиотеки
  3. OpenNews: В OpenBSD добавлен экстра-параноидальный режим работы malloc
  4. OpenNews: Релиз автоматического теста памяти memtest86+ 4.0
  5. OpenNews: Facebook открыл код для обработки ситуации нехватки памяти в системе
  6. OpenNews: Релиз Valgrind 3.15.0, инструментария для выявления проблем при работе с памятью
Лицензия: CC-BY
Тип: Программы
Ключевые слова: malloc, memory, mimalloc, microsoft
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (93) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:07, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +29 +/
    Вот кто делает истинный вклад в Open Source! Microsoft пришла — порядок навела!
     
     
  • 2.3, Аношка (?), 10:19, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ну это по сравнению с другими их поделками ( не в счет xbox и exchange )

    Торт, главное, что б в их "прозраности" никаких костылей не торчало, а выглядит оч даже съедобно (судя по анонсу )

     
     
  • 3.31, Антон (??), 13:24, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Microsoft - просто шильдик. Очевидно же что в компании есть много очень разных команд. Разработки, нужные, но не продающиеся, мс выводит в опенсорс, разумно же.
     
     
  • 4.47, MINIX (?), 18:57, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как это проживает в сравнении с другими быстрыми менеджерами памяти? Сравнивать с самыми тормозными - это конечно шик...
     
  • 3.59, Аноним (59), 21:12, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > не в счет xbox и exchange

    В счет в первую очередь

     
  • 3.97, And (??), 11:09, 30/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > выглядит оч даже съедобно (судя по анонсу )

    Так же было с форматом  docX, xlsx файлов Офис.

    Оказалось - сами в своей реализации отошли от своего стандарта.

    Поптыка работать со Скайп Фор Бизнес (это совершенно отдельная от "гражданского" Скайп реализация для Скайп+Аутлук, замена MS-Линка), использование MS Teams (платная замена Скайпа; Линк, Скайп Фор Бизнес больше не развивается, заменено платным сервисом), Аутлука 365, Офиса 365 под Вин 10, Офиса 2010 с Линком и т.д., опыт автоматизации развёртки Студио, работа при обновлениях со старшими администраторами MS продуктов на предприятии  - всё это внушает бооооооольшие опасения продуктов жизнедеятельности Microsoft.

    Линукс десктоп 10+ лет вёл себя гораздо более дружественней. При всей гибкости и обилии замен и новья под Л. всегда можно было решить вопрос. С Мелкомягкими - не было такого.

    Короче, Вы смотрите по делам, а не по пресс-релизам. :)))

     
  • 2.39, Аноним (39), 16:31, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Microsoft? Вклад? Да этому алгоритму сто лет в обед, в паскалях стандартный аллокатор так работает.
     
     
  • 3.70, ыы (?), 08:08, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вы какой паскаль имеете в виду? их очень много.. разных
     
  • 2.43, Зелень (?), 18:25, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не могу простить за нокию
     
     
  • 3.54, пох. (?), 20:05, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в смысле что не дали той самостоятельно обанкротиться?

     
     
  • 4.56, Аноним (39), 20:36, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Хороший такой "банкрот" через прихватизацию патентов и запрет заниматься телефонками на несколько лет.
     
     
  • 5.61, мелкософт (?), 22:24, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    дружище, когда я покупаю чей-то идущий на дно бизнес - я его таки покупаю, а не ... текст свёрнут, показать
     
     
  • 6.69, Анонимный прохожий (?), 07:20, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ...это говорит ровно о том, что владельцы бизнеса по уши в долгах,...

    Ни о чём это не говорит, особенно, учитывая, что директором работал инсайдер от Микрософт.

     
     
  • 7.76, nokian (?), 13:15, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    к тому моменту, как мы его сделали директором - именно что ВСЕ полимеры были проcpаны.
    Его и призвали-то только потому, что других дураков руководить обреченным бизнесом не нашлось.

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

     
     
  • 8.90, анониммус (?), 06:45, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    к тому моменту эппл уже своровала десяток патентов нокии ... текст свёрнут, показать
     
  • 3.60, zg_nico (ok), 21:34, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Не могу простить за нокию

    +1 Lumia 820 была разочарованием, причем не по железу - именно что по Windows Phone.

     
  • 2.88, Аноним (-), 00:12, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    M$ EEE! Запомни и вбей себе в мозг.
     

  • 1.2, Аноним (2), 10:17, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Судя по графикам, у них там монохромные мониторы, что ли?
     
     
  • 2.4, Аношка (?), 10:20, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А вы бы предпочли радугу из цветов для однотипных данных ?
     
     
  • 3.7, Аноним (2), 10:55, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так как системы во всех тестах идут в одном и том же порядке (и их количество везде одинаково), то в принципе можно вообще одним цветом показывать.
    Так же, так как mimalloc вообще(без всяких апелляций ;) самая ЛУЧШАЯ система, остальные можно (и даже нужно) не показывать, что бы у аудитории не оставалось никаких сомнений, что это ОНА единственная и самая совершенная система! ;)
    А так чо, удобно же ;)
     
  • 3.15, Аноним (15), 11:41, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно было столбики, соответствующие разным распределителям памяти, покрасить каждый в свой цвет.
     
  • 2.25, пох. (?), 12:32, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Судя по графикам, у них там монохромные мониторы, что ли?

    oocalc'ом рисовали - не хватило бюджета на ms office.

     

  • 1.6, Аноним (6), 10:38, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Короче говоря, они забили болт на экономию памяти и получили прирост производительности. Не сказать, чтобы результат был неожиданным.
     
     
  • 2.8, Аноним (8), 10:59, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    что

    >При этом в большинстве тестов также наблюдается более низкое потребления памяти, в некоторых ситуациях расход памяти удаётся снизить на 25%

     
     
  • 3.17, Аноним (6), 11:49, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А ты пойди по ссылке и посмотри второй график, который в новость почему-то не добавили. "В некоторых случаях" © расход памяти возрос на 300% (в одном отдельно взятом тесте, но не забываем, что они все синтетические).
     
     
  • 4.20, Ordu (ok), 12:11, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты про "note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs"?
     
     
  • 5.32, Аноним (6), 13:27, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну объясни, почему тогда с glibc он столько не жрёт.
     
     
  • 6.33, Ordu (ok), 13:40, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну объясни, почему тогда с glibc он столько не жрёт.

    Потому что с glibc тесты работают медленнее.

     
     
  • 7.34, Аноним (6), 13:44, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То есть
    > они забили болт на экономию памяти и получили прирост производительности

    что и требовалось доказать.

     
     
  • 8.35, Ordu (ok), 13:51, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет Если ты сравнишь графики производительности и расхода памяти на тесте xmall... текст свёрнут, показать
     
  • 2.9, Аноним (9), 11:02, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в большинстве тестов также наблюдается более низкое потребления памяти,
    > в некоторых ситуациях расход памяти удаётся снизить на 25%.
     
  • 2.14, Злюка (?), 11:36, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я сам не являюсь поклонником упомянутой в новости компании. Конечно, хотелось бы отпустить пару язвительных шуток про скорость, что нужно добавить в их логотип черточки с Формулы-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/
    Осталось дождаться независимых тестов и можно поздравить.
     
     
  • 3.18, Daemon (??), 11:58, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –15 +/
    При текущей стоимости памяти даже увеличение на 300% в угоду скорости работы не является критичным. КЕды вон жрут 2-4 гига оперативки и никто не жалуется.
     
     
  • 4.19, Anonimus (??), 12:06, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    вы кеды здорового человека как давно видели?
     
     
  • 5.45, Аноним (45), 18:33, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если кеды из коробки больны, то в массе это будут кеды больного человека. Исключения погоды не делают.
     
     
  • 6.64, НяшМяш (ok), 23:26, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из коробки могут быть только люди больны. Кеды уже давным давно вылечили.
     
  • 4.23, Аноним (23), 12:20, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ты кеды у себя в винде поставил?
     
  • 3.22, microsoft (?), 12:19, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Заслуга компании в том, что она оплатила эту работу, а потом ее открыла. А делать это могли любые аутсорсеры, не имеющие к М никакого отношения.
     
     
  • 4.26, Злюка (?), 12:33, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Заслуга компании здесь весьма сомнительна.
    Выложить проект размером с университетскую курсовую, такого же качества и выдавать это как нечто революционное, это, как мне кажется, немного некрасиво.
    Для компании уровня МС "оплатила" такую работу я просто промолчу.
    Первые независимые тесты подтверждают мои слова //github.com/microsoft/mimalloc/issues/11
    Сильно сомневаюсь, что сама компания будет использовать это в своих продуктах.
     
     
  • 5.37, Crazy Alex (ok), 14:45, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну да, проекты же только размером меряются. А issue... Ну нашли неудачный кейс - большие аллокации вместе с особенностями линуксового mmap. И что?
     
     
  • 6.98, And (??), 11:12, 30/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если проект маленький, а корпорация сильная, то, по малости проекта, не должно бы быть в нём "неудачных кейсов". Или сразу возникает сомнение в продукте.
     
  • 5.46, microsoft (?), 18:44, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я понимаю, плевать на содержание, главное объем.
     
  • 5.49, Аноним (49), 19:20, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы явно давно не видели студенческих курсовых.
     
  • 5.66, НяшМяш (ok), 23:31, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Если бы у всех программистов были бы хотя бы такие курсовые, то вряд ли мы сейчас жили бы в мире электронов и прочих гтк
     

  • 1.10, Андрей (??), 11:08, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надо бы теперь на чём-то реальном проверить:
    LD_PRELOAD=/usr/bin/libmimalloc.so firefox
     
     
  • 2.11, ааааа (?), 11:14, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А можно:
    export LD_PRELOAD=/usr/bin/libmimalloc.so
    прописать в /etc/profile?
     
     
  • 3.83, Michael Shigorin (ok), 22:01, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь была шутка про ~/.config.sys :)
     
     
  • 4.99, And (??), 11:13, 30/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И ~/.wine/emm386.exe
     
  • 2.85, test (??), 23:38, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Уже проверили на запросах к базе.
    jmalloc оказался в 2 раза быстрее.

    //github.com/microsoft/mimalloc/issues/11

     

  • 1.12, Аноним (-), 11:29, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Electron от майкрософта - вот будущее свободного програмного обеспечения.
     
     
  • 2.62, мелкософт (?), 22:25, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Electron от майкрософта - вот будущее свободного програмного обеспечения.

    агащасс. Мы для чего с гуглем-то договаривались? Элехтрон может быть только один!

     

  • 1.13, Аноним (13), 11:31, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://github.com/microsoft/mimalloc/issues/11
     
     
  • 2.24, пох. (?), 12:31, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вроде даже как обещали починить, но типа намекают, что оно немного не под такое использование было рассчитанно.

     
     
  • 3.28, Андрей (??), 13:07, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > оно немного не под такое использование было рассчитанно.
    > (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();
    }

     
     
  • 4.53, пох. (?), 20:04, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    разумеется, не обойтись - иначе зачем, по-твоему, jemalloc существует столько лет, но в glibc - используют совершенно другой?

    Но if(foo) может выполнять только сама программа - разработчик которой знает или хотя бы может пытаться угадать, как именно память будет использована. И выбирать себе аллокатор под конкретную задачу.
    Внутри вызова malloc() ты уже никак это не выяснишь.

     
     
  • 5.78, Андрей (??), 17:27, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Внутри вызова malloc() ты уже никак это не выяснишь.

    Тогда надо бы в POSIX добавить аналог fadvise только для malloc. И, похоже, уже давно надо было бы.

     
     
  • 6.81, пох. (?), 18:38, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это ж софт переписывать, весь.

    а тут можно обойтись LD_PRELOAD - по крайней мере, иногда.

     
  • 3.51, Аноним (6), 19:36, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > намекают, что оно немного не под такое использование было рассчитанно.

    То ли ещё будет, когда кто-нибудь решит эффективнсоть realloc() проверить…

     
  • 2.68, Аноним (8), 05:14, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Danila Kutenin
    >HSE FCS student

    к вопросу о курсовых

     
     
  • 3.84, Michael Shigorin (ok), 22:03, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А, так вот откуда бросившийся в глаза ещё из заголовка префикс "mima" :]
     

  • 1.16, Аноним (15), 11:42, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    >/usr/bin/libmimalloc.so

    Узнаю Венду, хоть тут конкретно и .so

     
  • 1.21, Аноним (23), 12:19, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сатья наживку заглотили можешь подсекать.
     
  • 1.27, Аноним (-), 12:55, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    От Майкрососфт нам ничего не нужно.
     
     
  • 2.30, Аноним (30), 13:20, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нам это тебе и твоему воображаемому другу?
     
     
  • 3.89, Аноним (-), 00:15, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    MS EEE тебе в щель.
     

  • 1.29, Аноним (29), 13:16, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Микрософт уже напоминает студентку 4 курса.
    https://anekdot.livejournal.com/2694119.html
     
     
  • 2.41, Аноним (41), 17:58, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По накопленным деньгам? )
     

  • 1.36, Аноним (2), 14:39, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что там с безопасТностью и сторонними каналами?
     
  • 1.38, Аноним (38), 16:19, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Hoard устарел в пользу https://github.com/plasma-umass/Mesh
     
  • 1.40, Аноним (40), 17:53, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Выделение и освобождение памяти происходит настолько редко, по сравнению с доступом к ней, что библиотека не даст прироста в реальных приложениях
     
     
  • 2.42, Аноним (42), 18:10, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже усугубит работу в многопоточных приложения. Аллокатор будет тратить большую часть работы.
     
     
  • 3.44, Зелень (?), 18:27, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Бойтесь нанайцев дары приносящих
     
  • 2.52, Ordu (ok), 19:54, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты проверял? Ну, то есть, твои теоретические выводы полагаются на то, что выделение/освобождение памяти примерно одинаково с доступом по скорости. Но это резко совсем не так. Выделение/освобождение гораздо-гораздо медленнее. Поэтому было бы интересно посмотреть на бенчмарки.
     
     
  • 3.55, Аноним (40), 20:34, 23/06/2019 Скрыто
  • –2 +/
     
     
  • 4.58, Ordu (ok), 20:41, 23/06/2019 Скрыто
  • +/
     
     
  • 5.63, пох. (?), 22:27, 23/06/2019 Скрыто
  • +/
     
  • 4.73, letsmac (ok), 10:26, 24/06/2019 Скрыто
  • +/
     
  • 2.65, НяшМяш (ok), 23:29, 23/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы ещё из тех, кто пишет программы, выделяя на старте память одним куском и в конце её освобождая? В большинстве современных приложений (например, тот же жеес на фронтенде) память частенько даже в цикле выделяется. Погуглите скриншоты любых мемори профайлеров - там ряды аллокаций просто сплошные без промежутков. Вот как раз в таких задачах очень может пригодиться.
     
     
  • 3.75, Аноним (75), 11:49, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что значит "еще из тех"?)
    Если вы современный смузихлеб, пишущий на электроне приложения жрущие по 16 Гб памяти чтобы отобразить чатик и выделяете по мегабайту в цикле - что ж, я рад, что всегда найдется работа для настоящих профессионалов, у которых на счету каждый байт. И да, даже однократный вызов динамической аллокации - полная жесть, и уважающий себя программист никогда так делать не будет.
     

  • 1.48, Аноним (48), 19:13, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    микрософт туда уже инкрустировал азуре или еще нет?
     
  • 1.57, IdeaFix (ok), 20:38, 23/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    К слову о крурсовых.... а старые преподы до сих пор просят запилить дефагментацию кучи? Типа указатель на указатель на указатель на массив указателей. Мы как-то лет 15 назад запилили.... и даже что-то со своим маллоком собрали. Даже работало.
     
     
  • 2.72, letsmac (ok), 10:22, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А почему бы и нет? Может кто Танненбаума не читал :-)
     

  • 1.71, Аноним qwerty_qwerty1 (?), 09:02, 24/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всю жизнь думал, что память выделяет ядро, а malloc это просто системный вызов. И тут такое откровение.  
     
     
  • 2.74, Совершенно другой аноним (?), 11:09, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    malloc() не системный вызов, а библиотечный. Системные вызовы это brk()/sbrk()/mmap()/munmap().
     
     
  • 3.92, qwerty_qwerty1 (?), 09:42, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    386 уже давно на свалке, как и книга K&R.

    http://www.opennet.ru/man.shtml?topic=malloc&category=3&russian=2

    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)).


     
  • 2.77, пох. (?), 13:19, 24/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >     И тут такое откровение.  

    типикал опеннет юзер

    и ничего, что исходник malloc в книжке Ритчи опубликован. Ему ведь и в голову не пришло ее читать.

     
     
  • 3.87, Аноним (40), 11:51, 25/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Где в договоре написано, что пользователи опеннета обязаны прочитать книгу ритчи?
     
     
  • 4.91, Аноним (91), 07:22, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пользовательи опеннет обязаны:
    1. при первом упоминании microsoft хотя бы раз отписаться про EEE - выполнено.
    2. при первом упоминании чего угодно графического хотя бы раз отписаться про Electron - выполнено
    3. Уважать только Си и баш-скрипты инициализации - в процессе
     
     
  • 5.96, Гость (??), 17:37, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Радио "радонеж" забыли.
     
  • 2.86, Аноним (40), 11:50, 25/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ОС просто гарантирует, что память одного приложения физически (в планке ОЗУ) не будет налазить на память другого приложения. То есть ОС выделяет ВИРТУАЛЬНОЕ адресное пространство, а приложение управляет виртуальной памятью как хочет.
     
     
  • 3.93, ютуб ютубов (?), 10:48, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    теперь ждём, когда это появится в Reactos
     
  • 3.95, Гость (??), 17:36, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Строго говоря не гарантирует, но пытается засегфолтить все бинарники, пытающиеся залезть за пределы своей песочницы.
     

  • 1.94, Аноним (94), 12:04, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А это точно проект мс, а не Xiaomi? Название слишком характерное
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру