Компания Google представила обновлённый вариант системы распределения памяти TCMalloc. Первый вариант TCMalloc был открыт в 2005 году и поставлялся в составе пакета gperftools (Google Performance Tools). Отныне TCMalloc, который используется во многих внутренних проектах Google, решено распространять в виде отдельного проекта. Код TCMalloc написан на С++ и доступен под лицензией Apache...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52364
Для интересующихся - нет, это не тот же tcmalloc из gperftools.https://github.com/gperftools/gperftools/issues/1169#issueco...
если читать новости дальше первого предложения, то именно так все в статье и написано. причем в самом начале
Кэп сегодня жжот напалмом! Но залогиниться всеж забыл.
Тот tcmalloc из gperftools запомнился тем, что вешал пк, когда памяти визуально ещё порядка 30% было. Странная штука была, в общем, напрасно его пихали.
1) tcmalloc медленнее чем gemalloc который применяется в fbsd
2) эти аллокаторы предназначены для бездумного использования. когда треды ломятся в одну точку по очередиединственное что тебе действительно нужно это mmap() и читать dodbook (Richard Fabian)
альтернатива: ищи простые реализации аллокаторов на gh и даже они дают прирост 500%
> 1) tcmalloc медленнее чем gemalloc который применяется в fbsdЧто, вот прямо во всех случаях? И вы, конечно, покажете бенчмарки, подтверждающие эту идею?
> 2) эти аллокаторы предназначены для бездумного использования. когда треды ломятся в одну точку по очереди
Есть какая-то статистика насколько это соответствует поведению разного софта?
А что по твоему происходит если треды начинают вызывать общий на всех malloc() ?Тебе действительно нужна эта mid-bloat-level прослойка, если ты такой умный?
моя основная мысль: прокачивай квалификацию или иди в питон
> А что по твоему происходит если треды начинают вызывать общий на всех malloc() ?#define "общий на всех malloc", для начала? Ну там как описание flow кто и что делал по тредам, анализа насколько этот flow типичен в том или ином сценарии для разных программ, а желательно еще и с пояснением почему именно фрибсдшная реализация типа-всех-задвинет и наверное какие-нибудь бенчи где это все было бы видно, чтоли. А то просто громкий тезис пальцем в небо - и, собственно, чего? КМК гугл
> Тебе действительно нужна эта mid-bloat-level прослойка, если ты такой умный?
Позволю себе методом "от противного": гугл скорее всего все-таки не настолько глупый и плохой в управлении, чтобы кодить такую штуку чисто для лулзов. И конструкция этой штуки как бы намекает.
> моя основная мысль: прокачивай квалификацию или иди в питон
Очешуенный аргумент. Что из ваших заявлений позволяет "прокачать квалификацию", например? :)
google Wave, g reader, g talk, g labs, picasa, Google Glass...да дох.много проектов были сделаны и закрыты от большого ума. Да?
про квалификацию: я начал с совета прочитать книгу. а ты хочешь сказать что вот твое приложение такое индивидуальное, что только анализ поможет? да, анализ покажет что ты особеный.
>google Wave, g reader, g talk, g labs, picasa, Google Glass...
>да дох.много проектов были сделаны и закрыты от большого ума. Да?Проекты закрывают потому что они перестают приносить достаточно бабла, а не потому что объявился какой-то дядя и сказал: "У вас тут говнокод, вы, похоже, нужных книжек не читали, закрывайтесь"
https://vc.ru/amp/52234
вот vc сделали статью с более полным перечнем закрытых проектов по годам и не везде известны причины закрытия.А у тебя "эксперт" для всего один шаблон.
причины закрытия всегда сводятся к одному: команда гугл потеряла интерес к проекту.
> причины закрытия всегда сводятся к одному: команда гугл потеряла интерес к проекту.Интерес они теряют если проект не приносит бабки и вбухивание усилий себя не окупает. Просто пострадать абстрактной фигней, без отдачи - извините, но так можно угробить даже большую компанию за обозримое время.
> google Wave, g reader, g talk, g labs, picasa, Google Glass...Google+ тогда уж.
> да дох.много проектов были сделаны и закрыты от большого ума. Да?
Именно! При скудоумии случается автоВАЗ: $ -> фуфло до упора. У гугли до 90% проектов пробные шары, спокойно списывают если не сработало. А если не списали, и появилось не вчера, значит видят некий пойнт. Вроде обычная логика.
> про квалификацию: я начал с совета прочитать книгу.
И совета юзать mmap... :\
> а ты хочешь сказать что вот твое приложение такое индивидуальное, что только
> анализ поможет? да, анализ покажет что ты особеный.Может и покажет. У меня специфичные юзкейсы, а для каких именно юзкейсов были те громкие заявы я и пытался понять.
И кстати с чего вы взяли что mmap() всем подходит как замена malloc()? Я не понимаю...
у гулага дойная корова реклама и они готовы убить youtube, android и что угодно, но высосать ее полностью и продать всех пользователей.призыв использовать mmap() означает, что нужно использовать его напрямую, включать голову и организовать memory pool если нужно.
если ты не уперся в пропускную способность памяти и не пришел к dod сам. Твои use кейсы вполне типичные.
> у гулага дойная корова реклама и они готовы убить youtube, android и
> что угодно, но высосать ее полностью и продать всех пользователей.Если они именно полностью - тогда у них поток денег кончится. Так что фиг, круговорот должен быть. Пипл должен это хавать и при том добровольно - т.к. приказать юзать свои сервисы, девайсы или что там еще гугл не может.
> призыв использовать mmap() означает, что нужно использовать его напрямую, включать голову
А таки malloc это часть стандарта стандартной либы си, а mmap - лишь posix. Портабельность снижается. Подмена malloc() таких проблем не создает.
> и организовать memory pool если нужно.
Может и свой аллокатор тогда сразу писать?
> Твои use кейсы вполне типичные.
Неа. Я тот еще системный извращенец.
> чтобы кодить такую штуку чисто для лулзовТот-же Go был ими взять на вооружение именно для того, чтоб нанимать ничего не умеющих макак писать код.
Как ни странно, макаки Go не осиливают, они лезут, в основном, в скриптоту, а из компилируемых предпочитают жабу.
А Go высоко оценили бывшие сишники, которым надоело заморачиваться с ручным управлением памятью и прочими неудобствами. Как-никак уже 2020 год и на рынке языков программирования есть из чего выбрать.
> Как ни странно, макаки Go не осиливают, они лезут, в основном, в
> скриптоту, а из компилируемых предпочитают жабу.Осиливают навороченную жабу с наследованием-полиморфизмом, dependency-injection, дженериками и аннотациями, но не осиливают Go?
Логика анонимов такая "логичная".> А Go высоко оценили бывшие сишники, которым надоело заморачиваться с ручным управлением памятью и прочими неудобствами.
Скорее, просто "бывшие сишники", осилившие только пару простеньких и примитивный парадигм, поддерживаемых Си - отчаянно не хотят приравнивать себя, любимых, к "макакам". Бережно лелеемое ЧСВ не позволяет, понимаш.
> Осиливают навороченную жабу с наследованием-полиморфизмом, dependency-injection, дженериками и аннотациямиА зачем это всё осиливать юному Java-разработчику? Слабать код можно как попало, и побольше копипасты, всё равно его через пару месяцев следующий юный разработчик будет с нуля переписывать.
Добро пожаловать в мир enterpise-grade solutions, Нео!
Осиливают навороченную жабу с наследованием-полиморфизмом, dependency-injection, дженериками и аннотациями, но не осиливают Си?
Логика анонимов такая "логичная".
> Осиливают навороченную жабу с наследованием-полиморфизмом, dependency-injection, дженериками
> и аннотациями, но не осиливают Си?
> Логика анонимов такая "логичная".А клоунада анонимов, когда от них требуется написать не вброс и не очередной ярлык "как знают все" такая клоунская.
>> Go высоко оценили бывшие сишникиоценили. но не бывшие и негативно (в контексте его использования в системном программирования). но для веб-макакинга язычёк вполне подходит
>> заморачиваться с ручным управлением памятью и прочими неудобствамиэтими вещами заморачиваются не по причине фанатизма, как вам может показаться со стороны, а по причине отсутствия альтернатив Си
Си обладает свойством zero runtime, гошка - нет. уже одного этого факта достаточно, чтобы сделать вывод о непригодности гошки для решения ряда задач, для которых подходит Си
гошка не может заменить Си, как бы этого ни хотелось смузистам
А libc.so и libgcc.so — они, конечно, просто так на диске валяются...
> А libc.so и libgcc.so — они, конечно, просто так на диске валяются...Они не являются НЕОТЪЕМЛИМЫМИ. Как доктор, умеющий создавать себе arena'у в абсолютно пустой железке грю! (вот прям сишкой, работающим в этой фазе с некоторыми ограничениями)
Go это не системный язык. Но все равно go это полное г. Как всегда распиарин для смузи потребителей. Сравнивать С и Go это как сравнивать «С» с смузи. Разные вещи для разных целей и пользователей. Один для программистов, другой для носителей обтягивающих джинс и ироничных наклеек на MacBook.
Что за идиоты тебя минусуют? Действительно, Си -- системный язык, а Go -- прикладной. Да, текущий Go отлично статически линкует, но это не чистый zero runtime. Чтобы понять разницу нужно компилять в нормальном окружении, а именно в любом дистре, основанном на чем угодно, кроме (e)glibc. Например, Alpine Linux, где вместо glibc используется musl. И если вы не знаете, что линковаться с libc вообще не обязательно, то это ваши трудности, а точнее поражение мозга Столлманом и его психопатией, что кто-то его код хочет утащить. Поэтому он сделал статическую линковку с glibc через одно место (тянем runtime) и все это объясняем "безопасностью", когда никто не мешает небезопасно статически нормально линковать openssl.
> чистый zero runtime.Это не чистый zero runtime, а вполне себе 6 метров рантайма (в хелловорлде) элементарно припертого с собой.
Я даже и покруче могу придумать. Ну вот например открываем страничку, а там loader на JS. Запускаем фабрисовский эмуль, грузим Linux, в нем свою прогу... так что идею притаскивания с собой своего рантайма можно, как видим, малость доразвить, притащив с собой вообще и эмулятор любого желаемого набора команд, и операционку на него, а backend на котором оно запустилось, в принципе, вообще не принципиален, чего уж там :)
Похоже, ты уже давно не программируешь, и не в курсе дел не только относительно Go, но и современного Си.
Ну просвети уже нас всех. Что там с go и что там с современным С? А то мы тут олдфаги с ANSI C то не вкусе дел.
> tcmalloc медленнее чем gemalloc который применяется в fbsdПро gemalloc я ничего не слышал, но если речь о jemalloc, то тесты с вами не согласны:
http://ithare.com/testing-memory-allocators-ptmalloc2-tcmall.../
Ты про эту картинку :
http://ithare.com/wp-content/uploads/malloc-cpu.pngУ tcmalloc экспоненциальный рост начиная с 13ти потоков и уже на 20 jemalloc жрет меньше.
"Производительность для не очень многопоточных приложений с большим количеством памяти на борту" вроде так в новости :)
как проснусь поищу тесты которые помню я. (еще более ужасные для tc)
(хотя в новости указанно что у гулага целых 2 tcmalloc)
Ага. То-есть, если копнуть, оказывается что если и делает - то мягко говоря не всегда и не везде, и на серебряную пулю ни разу не похоже. А пальцатый чудак рассуждающий про питон настолько крут что даже название алгоритма у него забагованое. Хы! Кстати а это какой из tcmalloc'ов на графике?
> Ага. То-есть, если копнуть, оказывается что если и делает - то мягко
> говоря не всегда и не везде, и на серебряную пулю ни разу не похоже.Это смотря чем копать:
>The second parameter we measured, was “memory overhead”. This is very important
>for overall performance, as the less RAM overhead we incur, the more efficient our
>caching is. To have an extremely rough approximation of this effect, we can think
>of allocator-having-2x-overhead, effectively wasting half of each level of caching,
>so instead of 12M L3 cache, with such an 2x-overhead-allocator we’ll run “as if”
>we have only 6M
>
>As we can see, from this perspective jemalloc comes out as a clear winner, with
>ptmalloc2 being the second-best, and tcmalloc trailing quite far behind for any
>number of threads > 1.-
> А пальцатый чудак рассуждающий про питон настолько крут что даже название алгоритма у него забагованое.
И то ли дело анонимные анонимы, совсем недавно с умным видом рассуждавшие о ручках, граблях и VLA в Аде …
Шиза косила наши ряды...
> Кстати а это какой из tcmalloc'ов на графике?Угадай, учитывая что сабж только на днях вылупился.
Это та технология, которая используется в Google chrome?
Тонко!
Оптимальный аллокатор обычно входит в стандартную библиотеку. Сторонние аллокаторы - это обычно трейдоф в сторону производительности в предположении, что памяти в компе бесконечно много.
Точнее, это самые разные варианты трейдоффа - банальное предположение и количестве попыток выделения памяти из разных потоков может уже много чего поменять. Или, как у меня когда-то было, когда понятен специфический паттерн запросов. В общем, те, кому оно нужно, уже об этом знают.
> x86, PPCARM не поддерживается? Как подвезут - приходите. Следующий..
...и Гугл опустив голову грустно побрёл прочь допиливать поддержку АРМа для клалафуды.
Не для Клалафуды, а для свего же родного Андрюши.
пипл и так хавает. А тех, кто могли такое написать, мы уже уволили - какие-то они нетолерантные были, и к тому же денег много хотели, а испытывать состояние глубочайшего счастья от самого факта быть достойным рабом нашей корпорации - почему-то нет.
Breaking news! Клава наказывает Гугл!!!
О, круто!
- Если гугл не релизит сорцы, пох верещит что негодяи, патчи зажимают, на опенсорсе паразитируют!!!111
- Если гугл релизит сорцы, его сосед по палате вопит что его любимая шняга там не поддерживается, негодяи!!!1111Я даже знаю как вам всем таким красивым угодить. Допилить AI и прислать вам уже наконец терминаторов, поговорить по душам. Вот тогда вам обоим станет уже наконец хорошо.
Ну а не такое уг релизнуть гугль не мог?Вот и остается гадать - то ли копрорация добра намеренно релизит все так, чтоб только выкрасить и выбросить (как это произошло с in-kernel lustre, причем, (совпадение?! Конечно, совпадение!) сразу после того как сдох "нинужнанинужна, есть в ядре!" fuse-lustre), то ли это карма у них такая...
> Ну а не такое уг релизнуть гугль не мог?Ты хотел сорцы? Вот, пожалуйста, в виде как есть. А то задачи гугла совпадут с твоими никто и не обещал.
> Вот и остается гадать - то ли копрорация добра намеренно релизит все
> так, чтоб только выкрасить и выброситьСорц отгрузили, а окажется ли он полезен тебе, в твоих задачах - наверное не проблема гугла?
Если тебе надо код от чуваков которые хотят всех осчастливить, даже не спрашивая надо ли им это, это ты к пыхтонрастам каким, у них есть для тебя множество кульных шняг. Вон, весь гитхаб к твоим услугам, обкачайся :)
> есть в ядре!" fuse-lustre), то ли это карма у них такая...
Видимо таки карма. Было б нужно кому всерьез - не сдохло, наверное.
Вон...
"гении" хухля не осилили аллокатор на чистом С. "прогресс", однако...
а почему нужно писать именно на Си? (я сам немного сишник если что, но написание malloc даже уровня K&R malloc нахожу сомнительным удовольствием)на Си уже полно аллокаторов (jemalloc, тот который из glibc (не помню названия), другие), почему не написать на плюсах?
>> почему не написать на плюсах?1) потому что современные реализации С++ являются, по сути, языком сверхвысокого уровня и не подходят для решения задач из области системного прграммирования
2) создание аллокатора памяти - типичная задача, для решения которой необходим чистый С
Может быть, лет через 5-10 вы случайно наткнётесь на этот свой комментарий и с ностальгической улыбкой подумаете, какой же вы были смешной и глупый.Но сейчас — вы просто позорно слились, с чем вас и поздравляю.
дайте угадаю - вы STL-фаг, который без разбору использует возможности стандартной библиотеки где попало
вы, конечно, можете использовать возможности "современного" С++ при разработке аллокатора памяти в том числе, только не надо заявлять о каких-то "сливах" тем людям, которые более разборчивы в выборе применяемых инструментов
> Но сейчас — вы просто позорно слились, с чем вас и поздравляю.На плюсах нет ни 1 сколь-нибудь востребованной операционки. Самое крутое системное программирование на плюсах которое в бошку приходит - ардуина, лол! Только там оно в режиме этакого яваскрипта для нубов, уж сорь! Их предел C++ это serial.begin() XD.
> Самое крутое системное программирование
> на плюсах которое в бошку приходит - ардуина, лол!Haiku? Genode? Не, не слышал, но ценное мнение …
> Haiku? Genode? Не, не слышал, но ценное мнение …Еще реактос надо вспомнить. Без него список жесткой маргинальщины был бы неполным.
Кстати, за всю свою жизнь я видел 1 живого пользователя гайки, 0 живых пользователей реактоса и ни разу в жизни не пересекался с генодой вообще. При всем моем интересе к странным железкам и юзкейсам.
>На плюсах нет ни 1 сколь-нибудь востребованной операционки.В манямирках-то конечно. I/O Kit из OSX пойдет как пример системного программирования на плюсах?
> В манямирках-то конечно. I/O Kit из OSX пойдет как пример системного программирования
> на плюсах?IOKit это как я понимаю некая нашлепка над ядром. А практически вся система, включая кернель, дрова и прочее таки си. А так если какие апликухи и прочее брать, окажется что у эпла там еще и swift какой-нибудь, но вот сказать что "система написана на swift" будет все же странно.
Винда пойдёт в качестве примера? Уж как минимум, всё, что использует COM - это либо плюсы, либо .NET. А учитывая, что MSVC - это компилятор С++, который случайно поддерживает подмножество C, вполне вероятно, что там всё, включая ядро, на C++ (который, возможно, используется как C с классами, но тем не менее).
> Винда пойдёт в качестве примера? Уж как минимум, всё, что использует COM
> - это либо плюсы, либо .NET.А в каком месте COM является системным программированием? Системное в NT это вообще NT API, так уж, по большому счету. И у него интерфейс совсем не плюсатый, ну вообще никак. А внутрях... внутрях я даже не знаю как их кёrnel называть, там нечто вообще совсем ms-specific и на этом никто кроме ms на данное планете не изъясняется.
> А учитывая, что MSVC - это компилятор С++, который случайно поддерживает подмножество C,
...потому что >=C99 ms так и не осилил и в результате большинство системщиков и низкоуровневых алгоритмистов с этой шняги сбежало gcc и шланг :). А многие еще и в линукс, за что MS большое человеческое спасибо! А визгливых дотнетчиков они, так и быть, себе могут оставить, у нас и своих пихтонрастов избыток, могут даже кого-нибудь забрать, для компании дотнетчикам :)
> вполне вероятно, что там всё, включая ядро, на C++ (который, возможно, используется как C
> с классами, но тем не менее).Виденные юзеры VS юзали "плюсы" для того чтобы их си выглядел как C99. Нет, там даже классов в 95% случаев нет. Несомненно, в винде бывают и крутые плюсовики. Но их вообще немного и они по жизни специфичные, типа игроделов.
Гугл вообще странноватые типы - плюсы юзают часто вообще хз зачем. Потому что V2 лучше V1, а something+ лучше чем something, а уж если something++ так это вообще офигеть, дайте два.Но это еще что, я вот видел как для билдовки проекта на два файла предлагали билдсистему на яве втулить на полном серьезе. Я, правда, решил что gcc *.c -o out мне на проекте такого уровня как-то сильно проще и быстрее, бида-бида :)
Здесь файлов поболее двух, но> Building TCMalloc
> Bazel is the official build system for TCMalloc.
> Здесь файлов поболее двух, но...но да, гугол и тут верен себе, используя по сути свой внутренний крап :). Ну это ты еще хромиум билдить не пытался просто, во где полный крындец. Надо скачать половину интернета. Точнее, оно само попытается скачать вам половину интернета. Хрен знает откуда и зачем, но у этих гамадрилов в их зоо^W кампусе видите ли такой воркфлоу.
Гугл, как и дюбая вменяемая корпорация, смотрит ещё на сопутствующие услоаия. Если плюсовая команда есть, для плюсового кода гораздо лучше средства статического анализа, есть куча другого плюсового софта, который с новым проектом будет связан - проще на плюсах пилить. Плюс плюсы лают более поддерживаемый код. С системами сборки тем более - чем пользуются - с тем и выкладывают.
> Гугл, как и дюбая вменяемая корпорация, смотрит ещё на сопутствующие услоаия.На самом деле все проще - в упомянутом случае прогер просто хватнул привычный тул (имеющий маргинальное хождение вне гуглокорпа) и безбашенно заюзал. После всеобщего офигения "вы с дуба упали?" и "нельзя ли хотя-бы makefile?" они как раз второй вариант и заимплементили.
> Если плюсовая команда есть, для плюсового кода гораздо лучше средства статического анализа,
Да неужели? На си++ можно наворачивать крайне навороченные и неочевидные конструкции, с хрензнает какими побочными эффектами, и вообразить себе статический анализатор, который сможет вдуплить во все приколы плюсовиков и то что из этого следует - я как-то затрудняюсь. Вот си да, простой, поэтому его статический анализ еще имеет какие-то перспективы.
> есть куча другого плюсового софта, который с новым проектом будет связан
> - проще на плюсах пилить.Попытка поумничать не удалась - это была standalone прога, самодостаточная по функциональности и никуда не встраивающаяся вроде как.
> Плюс плюсы лают более поддерживаемый код.
Ага, ща! Сколько плюсовиков, столько и стилей их кода. Это здорово повышает порог вхождения, вплоть до того что я видел код который вообще никто майнтайнить не может. У гугла наверное есть какие-то coding rules и guidelines лимитирующие развитие п-ца, но вообще так бывает, и на плюсах это как 2 байта переслать.
> С системами сборки тем более - чем пользуются - с тем и выкладывают.
Ну дык. А смысл вываливать внутрикорп крап для тех кто !google? Ну вот перцу это не очень вежливо и объяснили. Но вообще мозг полезно врубать до вываливания проекта, а не постфактум когда тебя фекалиями закидали уже :)
Скажите спасибо, что на джаве не написали.
Спасибо, что не на расте!
а что не так с растом?
Вызывает пригорания у известной аудитории. ;-)
Небезопасен.
А я абзолюдно збагоен.
> а что не так с растом?Вендорлокнут на мозиллу.корп, которая делом доказала что те еще типы, даже хреновее чем гугл. И зависеть от именно этих - да ктулху упаси.
Они собираются Rust Foundation создать для отвязки от мозиллы.
> Они собираются Rust Foundation создать для отвязки от мозиллы.Ну вот когда и если, и еще и репы от них отвяжут - тогда и приходите. А покамест я мозильских вендорлоков с аддонами уже вкусил выше крыши и за добавкой не приду нифига, еще не хватало чтоб меня так в программировании с компонентами и либами могли натянуть.
https://github.com/microsoft/mimalloc
https://github.com/plasma-umass/Mesh
https://github.com/mjansson/rpmalloc
https://github.com/SergeyMakeev/smmalloc
https://github.com/ennorehling/dlmalloc
https://github.com/r-lyeh-archived/ltalloc
https://github.com/emeryberger/Hoard
https://github.com/jemalloc/jemalloc
https://github.com/ezrosent/allocators-rs
что за сорта г?
https://google.github.io/tcmalloc/ сабж забыл
Гугл уже взялся и рынок памяти перераспределять?
При выделении память автоматически инициализируется ненавязчивой рекламной строкой.
А телеметрия отключается?
Я пьян, и malloc это
Lock
mmap(Null,...)
Unlock
Это simple malloc в uClibc.
А mmap это сискол.
Поговорю пьяный сам с собой, ничего парни?
Теперь господа классные программисты пусть переделают это в реализацию mmap, допустим для ядра Linux. А malloc это всего лишь частный случай mmap. Его усложнять пощадите наши мозги.
> Теперь господа классные программисты пусть переделают это в реализацию mmap, допустим для
> ядра Linux. А malloc это всего лишь частный случай mmap. Его
> усложнять пощадите наши мозги.Malloc не всегда mmap. Это раз. Два - могут быть какие-то специальные соображения, при которых mmap не катит. Ну вот конкретно в сабже оно пошло из профайлера. А в случае mmap это интересно как должно быть? В смысле, профайлинг? А, сразу системозависимыми тулзами, лезущими в кишки ядра? :)
Нет, malloc всегда mmap. Ты анон ошибаешься. Посмотри исходники. newlib uClibc musl.
И в BSD тоже malloc вызывает syscall mmap.
В BSD вообще libc вызывает 5 syscall ов. Остальное ассемблер. Посмотришь на open - должен быть сискол, а там open.S. Хрен разберёшься. Мда, пьян.
> В BSD вообще libc вызывает 5 syscall ов. Остальное ассемблер. Посмотришь на
> open - должен быть сискол, а там open.S. Хрен разберёшься. Мда, пьян.Ну позырь сорц mirai, увидь как хацкеры делают подобные выходки вообще без асма и "кроссплатформенно" *.
* покуда это остается ядром Linux, но таки под ~дюжину архитектур CPU.
> Нет, malloc всегда mmap. Ты анон ошибаешься. Посмотри исходники.А ежели я найду malloc который не mmap? :) А то malloc ВНЕЗАПНО бывает даже на штуках где mmap тупо нету, в бутлоадерах там всяких, допустим :). Си вообще забавная штука, да и рантайм окружения бывают разные.
> newlib uClibc musl.
Откуда следует что это единственный вариант реализации? Не понимаю.
Ну в бутлоадерах тупо передвигается указатель на свободную память. Там и free нету, он только располагает в памяти. Это просто.
Нет системного вызова malloc. Есть mmap.
Можно только урвать побольше, а потом выдавать.
Или по твоему: libc один раз запрашивает mmap, а потом из него выделяет malloc'и? А... Может и так. С ldpreload.
> Или по твоему: libc один раз запрашивает mmap, а потом из него
> выделяет malloc'и? А... Может и так. С ldpreload.Еще можно man brk и sbrk, чтоли.
deprecated и в linux, bsd... стек это тоже mmap () остался только один* сискол на все
> deprecated и в linux, bsd...Чего-то в Linux Programmer's manual вообще совсем ни звука про то что это - deprecated. Единственное что там указано - дескать, для _портабельного_ выделения памяти лучше юзайте в своих программах malloc(), дескать.
> стек это тоже mmap () остался только один* сискол на все
Ну вот brk/sbrk таки другие, согласно LPM sbrk реализован как дерг brk + код либы. Однако brk все-таки отдельный сискол как ни крути.
> А malloc это всего лишь частный случай mmapРовно наоборот. mmap -- это частный случай malloc. Иногда malloc безболезненно можно заменить на mmap, иногда даже с профитом -- если ты выделяешь помногу и редко, то офигенно должно зайти.
Но если ты выделяешь/освобождаешь довольно часто, то каждый раз платить тактами процессора за сисколл -- слишком жирно будет. Тут история та же самая что и с read/write и fread/fwrite. Буферизованный ввод/вывод резко быстрее, если тебе надо читать/писать маленькими кусками.
> Ровно наоборот. mmap -- это частный случай malloc.Да ну ладно?! А сможешь malloc()-ом по файлу шариться? В mmap так можно и это половина его предназначения :)
> что и с read/write и fread/fwrite. Буферизованный ввод/вывод резко быстрее, если
> тебе надо читать/писать маленькими кусками.А прикинь, mmap()-ом еще можно файло в память отмаппить как "группу адресов" и дальше делать файловый IO как будто это у нас такой очень большой массив* и при этом ... ну, по сути, почти интерфейс к дисковому кэшу ядра, совершенно прозрачный и выглядящий как просто регион памяти.
* На 32-битных архитектурах массив "почему-то" не такой уж и большой, что накладывает ограничения на размеры файлов :)
Мы говорим про выделение памяти, или про файловый ввод-вывод? Мне казалось про первое, не?
Ты беседу-то читай целиком, прежде чем влезать в неё.
Интересно, добавили работу в системах с musl libc. Было бы здорово!