После года разработки представлен релиз стандартной Си-библиотеки Musl 1.2.4, предоставляющей реализацию libc, которая подходит для применения как на стационарных ПК и серверах, так и на мобильных системах, сочетая полноценную поддержку стандартов (как в Glibc) с небольшим размером, низким потреблением ресурсов и высокой производительностью (как в uClibc, dietlibc и Android Bionic). Имеется поддержка всех обязательных интерфейсов C99 и POSIX 2008, а также частично C11 и набор расширений для многопоточного программирования (POSIX threads), управления памятью и работы с локалями. Код Musl поставляется под свободной лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59069
Пример того каким должен быть опенсорсный проект. Смотришь в исходники - качественный чистый код. Смотришь в исходники GLIBC - абсолютно нечитаемая лапша из define-ов, в которой в принципе человеку невозможно разобраться.
типичный опенсорс проект, это точно, то есть нинужный никому огрызок
Никому нинужный, кроме ембеддед дистрибутивов линуха типа альпина, на котором основаны 99% докер-образов, и т. д.
>решeта типа альпинаfixed
Да и производительность рза в 2 ниже, чо уж там.
> то есть нинужный никому огрызокНужный корпорациям, которые на основе этого огрызка продают готовые решения за деньги.
Для того, чтобы поверх этого писать качественный корпоративный код, типаdouble rest(float a, float b)
{
float res=a*b;
for (int i=0; i<999999999999; i++)
if (i <= res && i + 1 > res) {res = res - i; break;}
return res;
}- вполне сойдёт
Че за жесть?
Это откуда такое ?
Хороший и качественный бенчмарк. А по названию функции понятно что она для отдыха. Самое время побенчить.
> нинужный никомуМнение человека, не умеющего писать по русски, очень важно!
> в которой в принципе человеку невозможно разобраться.Так на это и рассчет + подцепить себя в зависимости - везде
Да, glibc у всех, а это поделие только у разраба и его бабушки.
Навязывается в Alpine, в результате чего сложился миф, что "докер - это тормоза".
Alpine часто используется в качестве основы для докер-контейнеров, а работа с памятью в мюслях не быстрая.
Единственный источник тормозов в musl - это аллокатор.
Но никто не мешает использовать любой другой, jemalloc тот же.
Разработчики OpenWrt с тобой не согласны: https://www.opennet.me/opennews/art.shtml?num=42439
пример мюслей
везде запускается https://github.com/JFreegman/toxic/releases/tag/v0.12.0
спасибо поржал над это поделкой
Покажи свой гитхаб, хочу тоже поржать над экспертом хеллоуворлдщиком.
Несколько лет назад мюсли были не совместимы с tcmalloc, от которой зависимы многие серьёзные проекты, такие как базы данных, где тонкая работа с памятью ключевой момент производительности. И это по-моему единственная проблема из сложнорешаемых, которая не позволяла просто так взять и перейти на мюсли по дефолту для любого дистрибутива. Сложнорешаемосто была на стороне разработчиков tcmalloc и никак не зависела от команды musl. Интересно, как сейчас обстоят дела?
Work on musl has also been sponsored by:
The Zig Programming LanguageОго.
Локаль уже осилили?
У этого поделия до сих пор стек 128-256 КБ, чтобы некоторый софт, полагаясь на нормальный размер стека, мог и упасть? А его аллокатор, что пару лет назад катастрофически отставал даже от glibc malloc (не говоря уже о mimalloc/jemalloc) в многопоточных приложениях, его исправили?
Порадуете цитатой стандарта, где определён нормальный размер стека?
Стандарт в опенсорсе, а ты смешной.
А ты Чат Жэ-Пэ-Тэ и потому не знаешь, что у языка Си есть стандарт. И даже название новости не смог прочитать.
> А ты Чат Жэ-Пэ-ТэНет, это вы Чат Жэ-Пэ-Тэ
Путать теплое с мягким это твоя судьба. Ты не только смешон, но тебя ещё и жаль.
А мне тебя не жаль. У тебя нет ни имени, ни гитхаба - некого жалеть.
Ванузнику нуби никто слова не давал.
> никто слова не давал.Ну да, если у кого-то нет ни работ, ни имени - иначе говоря, он никто.
Опенсорс придерживается, например, RFC.
Да, это заметно.
У тебя, внезапно, тырнет неработоспособен?
Размер стека можно задать вручную -Wl,-z,stack-size=N
> Размер стека можно задать вручную -Wl,-z,stack-size=NНе гоже "князьям" возиться с такой лабудой, их величества привыкли к include, include, include then next - next - next, и то под хорошим настроением, а то вообще пусть холопы в виде ЧатГПТ за них думают
Nvidia moment
> В DNS-резолвер добавлена возможность отправки запроса по TCP в случае неудачного обращения по UDPЭто пожалуй самое полезное !
А зачем DNS-резолвер, в Си-библиотеке?
man gethostbyname
Пф, ещё одна "свободная и открытая" реализация стандартной библиотеки Си. Как будто C и C++ не созданы были с расчетом на привязку к конкретной платформе и операционной системе. Эти "кроссплатформенные" решения всегда теряют в производительности и оптимизации под конкретную архитектуру. Мне и моим приложениям на Windows нужна именно та библиотека, которая оптимизирована специально под эту ОС. И пусть сторонники "свободного ПО" проповедуют подобные решения, мне они не интересны!
О, какой же отсталый и косный взгляд! Windows и C++ давно устарели и должны уйти в прошлое.
GCC и Clang с Rust уже возвели кроссплатформенные компиляторы на новый уровень, обеспечив лучшую производительность и безопасность, чем Microsoft’s ПО и твой устаревший С++.
Привязка к конкретной платформе? Абсурд! Давайте полностью откажемся от этих наследственных оков и создадим полностью переносимое, быстрое и безопасное ПО!
“Оптимизация под конкретную архитектуру” - отмирающий подход. Современные компиляторы и языки способны генерировать код, оптимальный для любой архитектуры. Освободимся от ограничивающей привязки к Windows, только тогда наше ПО достигнет истинной свободы!
А тебе, “любителю оптимизации под Windows”, я могу только посоветовать пересесть на достойную платформу - Linux.
Ха, как ни посмотри, а этот "прогрессивный" воззвание полно отсталых идей, выдаваемых за передовые.
Во-первых, уже сейчас существуют кроссплатформенные решения на базе С++, GCC и прочего - и они далеко не превосходят Windows и мою привязку к ней в плане производительности или безопасности. Просто предлагают иную траекторию развития, более удобную для "открытого кода".
Во-вторых, полная отмена привязки к архитектуре - путь к хаосу, а не прогрессу. Именно тщательная оптимизация под архитектуру лежит в основе высокопроизводительных систем.
Наконец, я и так свободен в выборе платформы - и не намерен отказываться от преимуществ Windows ради экспериментов с Linux.
Мои приложения должны работать, а не демонстрировать "прогрессивные" технологии. И если меня устраивает Windows, С++ и привязка к конкретным архитектурам, то это и есть "достойный" и разумный подход.А "передовые" идеи, подобные полной отмене привязки к архитектуре и переходу на Linux, я оставлю свободным энтузиастам - мои пользователи просят стабильных программ, а не постоянных экспериментов. Так что можешь мне только посоветовать остаться на Windows, ценимом мною за надежность и производительность, а не за "прогрессивность"!
> Мои приложения должны работать, а не демонстрировать "прогрессивные"
> технологии. И если меня устраивает Windows, С++ и привязка
> к конкретным архитектурам, то это и есть "достойный" и разумный
> подход.Ваши пользователи завтра (если не позавчера) заслуженно отведут Вас хорошо если просто к следователю как саботажника, у которого с 2014 года между левым ухом и правым ухом так ничего и не щёлкнуло.
А тот -- возможно, и не отправит к психиатру выяснять, почему же не щёлкнуло и в 2022, когда "преимущества Windows" были наглядней некуда изложены непосредственно поставщиком.
Ну то есть даже правильно пишете, если вычеркнуть Windows. А будете за неё цепляться -- окажетесь вычеркнуты вместе с ней. Не угроза, лишь прогноз.
Можете начать с http://mcst.ru/elbrus_prog по части оптимизации, там есть платформонезависимые штуки :-)
// отправлено с e2k-alt-linux
> Ну то есть даже правильно пишете, если вычеркнуть Windows.aka "Неправильная у вас точка зрения, думайте лучше как я".
>> Мои приложения должны работать, а не демонстрировать "прогрессивные"
>> технологии. И если меня устраивает Windows, С++ и привязка
>> к конкретным архитектурам, то это и есть "достойный" и разумный
>> подход.
> Ваши пользователи завтра (если не позавчера) заслуженно отведут Вас хорошо если просто
> к следователю как саботажника, у которого с 2014 года между левым
> ухом и правым ухом так ничего и не щёлкнуло.У меня щёлкнуло. Тогда я нарыл в глубинах Qt5 велосипедный dynamic_cast, реализованный как обёртка над dynamic_cast, и понял, что это нельзя использовать, потому что очень скоро компания начнёт выкидывать legacy. Я немного ошибся в прогнозе. Qt не только забросила Qt5, но и ушла из России. Что не мешает этот неподдерживаемый код продавать.
Кто решит оспорить "неподдерживаемый", пусть расскажет, как активировать отображение контекстного меню не по нажатию ПКМ, а по отпусканию. Это штатная возможность Qt5, не используемая в KDE (много лет висит баг), и где-то здесь валяется мой пример, как это делается.
> Можете начать с http://mcst.ru/elbrus_prog по части оптимизации, там есть платформонезависимые
> штуки :-)Зачем Вы это делаете? Я пробовал начать. Лично Вам оказалось не интересно.
Шигорин теперь за мнения технического характера грозит гулагом, когда они ему не нравятся. Что дальше, Миш? Казалось бы уже всё, дальше некуда деградировать, но ты раз за разом находишь способы продолжить.
Он не грозит. Он почему-то полагает, что Linux в России не повторит судьбу Windows. Тогда как Microsoft, IBM (RedHat) и прочие спонсоры ушли из России, а компания Meta запрещена и её сотрудники не принимают патчи. При этом сам он никаких гарантий дать не хочет.
> Привязка к конкретной платформе? Абсурд!
> пересесть на достойную платформу - Linux.A.
Напиши в комитетет по стандартизации C++. А то они там не вкурсе, что пора им расходиться и прекращать свою устаревшую деятельность.
Сторонник несвободного ПО, что забыл на ресурсе, посвящённом свободному ПО?
Да кто им нужна эта их "мобильная оптимизация" и "низкое потребление ресурсов"? Мы же пишем приложения для настоящих компьютеров с мощными процессорами, а не для карманных гаджетов. Пусть эти "кроссплатформенные" решения и подходят для Android, настоящие программисты C++ предпочитают библиотеки, тщательно отполированные под Windows, с расширенной функциональностью и максимальной производительностью. Мне нужна не оптимизация под "мобильные устройства", а максимальная мощь для настольных приложений!
Ах, вот оно как! Судя по всему, ты - типичный "архаичный" программист, пишущий исключительно для мощных настольных систем под Windows, а потому полностью игнорирующий тренды мобильных и встроенных устройств.
А те, между прочим, уже давно стали доминирующей платформой для программного обеспечения, и твой узкий фокус на настольные системы скоро окажется в полной изоляции.
Мобильная оптимизация и низкое потребление ресурсов - не пустые слова, а ключевые требования к любому современному ПО. И если ты не в состоянии создать решение, удовлетворяющее им, то твои программы обречены на провал.
Что же до “тщательно отполированных под Windows библиотек”, то их эра давно миновала. Современные кроссплатформенные технологии обеспечивают равную или даже превосходящую производительность на любой ОС.
Вместо того, чтобы упорствовать в своей “предпочтении Windows”, ты бы с успехом мог портировать свои приложения на Linux. Там, с новейшими инструментами, твоя C++-программа без труда превзойдёт всё, что когда-либо было создано на Windows.
Увы, но твой век уже прошёл. Мир прогрессирует, а ты остаёшься в прошлом - такова горькая участь любого “архаичного” программиста. Адаптируйся или исчезни!
Хм, так это же классическая история об "отсталых консерваторах", не способных воспринять "прогрессивные идеи будущего".
А будущее, согласно этому видению, и есть погоня за мобильностью, оптимизация под ограниченные ресурсы и переход всего ПО на "кроссплатформенные" технологии с Linux во главе.
Однако это всего лишь один из возможных сценариев развития, а не единственно верный и прогрессивный. И ничто не доказывает, что он обречён на победу, пусть даже мобильные устройства и доминируют численно.Настольные системы по-прежнему формируют основу для большинства серьёзных приложений и технологий. И если я сужу интересы своих приложений и своей работы с позиций именно этой области применения, то в этом нет ничего "архаичного". Это просто разумный выбор целевой платформы.
Аналогично, привязка к конкретным архитектурам - не реликт прошлого, а способ достижения максимальной эффективности и производительности, важный для серьёзных профессиональных приложений.
"Кроссплатформенность" же и "низкое потребление ресурсов" - не самоцели, а средства, которые я могу использовать лишь в той мере, в какой это не помешает целям моих приложений.Вот почему я и отвергаю идею адаптации к "трендам будущего" и советы портировать приложения на Linux. Моё будущее - это продолжение работы над надёжными и эффективными решениями для настольных систем под Windows.
А твои "новейшие инструменты" и "кроссплатформенные технологии" могут идти собственной дорогой - моя тропа уже выбрана и больше меня не интересуют никакие иные "современные" воззрения!
Ты бы попробовал посидеть с годик на Musl скажем в Void Linux перестал бы чушь пороть. Настольные системы понятие растяжимое и их простые версии отстают от мобильных процессоров очень часто потому как все инновации сосредоточены в мобильном сегменте, ну может отчасти серверный затронут многоядерными армами.
Выбор идет у людей между быть привязанным к одной платформе или сразу писать переносимый код. Твое мнение отвергания безынтересно в принципе.
Твоя баланда у корыта никому не сдалась. Винда нужна в исключительных случаях вроде поддержки звуковых карт, которые поломали в линуксе объявив рабочими например.
Ни ядро не собрать, ни чего-то поэкспериментировать - ничего нельзя в винде в принципе фанат ты гребаный.
> Вот почемуЗанятная каша в голове, даже разбирать незачем -- в рамочку и на стенку.
Вообще такое очучение последнее время, что на форуме вновь работает пара экземпляров http://wiki.opennet.ru/MSSP и думают, что уши попыток посрывать стек смесью истинных и ложных утверждений не торчат.
Да твоя бухгалтерия без этого не посчитается.
Может линковаться статически в отличии от убожества glibc. Ещё бы производительность подтянуть
> Устранена серия проблем в функциях семейства printf.Что, опять переполнение с выполнением кода?
>> Устранена серия проблем в функциях семейства printf.
> Что, опять переполнение с выполнением кода?Опять автономный майнтайнер не умеет ходить по ссылкам и читать.
- fwprintf didn't print most fields on open_wmemstream FILEs
- wide printf %lc ignored field width
- wide printf erroneously processed %n after encoding errors
- use of wide printf %9$ argument slot overflowed undersized buffer
- swprintf malfunctioned on nul character in output
Оптимизация.
Зная, насколько криворук Рич Фелкер, вполне закономерно предположить, что он опять допустил переполнения в printf.
Действительно, так и есть. Можно было не ходить по ссылкам.
> вполне закономерно предположить, что он опять допустил
> переполнения в printf."опять переполнение с выполнением кода"
> Действительно, так и есть.
Пока есть подмена тезиса и попытка заболтать существенную часть.
>Код Musl поставляется под свободной лицензией MIT.В этом и кроется фатальная ошибка.
Так мой коронный вопрос: списки, деревья, хеши, бтрии, индексы, регулярки есть в этой "стандартной" библиотеке?
Ты путаешь стандартную библиотеку С с библиотекой С++.
Твоё объяснение зачем они там должны быть?
Юзай GLib. Там всё это есть и даже больше. Наверное, даже с musl он соберётся (честно, не пробовал).
>В DNS-резолвер добавлена возможность отправки запроса по TCP в случае неудачного обращения по UDP, что решило проблему с запросом больших DNS-записей и наладило совместимость с рекурсивными DNS-серверами, не поддерживающими отдачу части результата в обрезанных UDP-ответах. Попутно устранено ещё несколько недоработок, связанных с DNS, таких как невозможность раздельной обработки состояний NODATA и NXDOMAIN."Так вот она чо, Петрович"
Видать роутер с Musl собран, а я все гадал, каког... т.е. почему DNS по TCP не ходит.
Здесь некоторые пишут, что musl медленнее glibc. Я решил это проверить и собрал два минимальных образа BuildRoot для OrangePI_PC с двумя этими библиотеками. Конфигурация по умолчанию из BuildRoot, только изменил версию ядра на актуальную. Вот что получилось: https://cloud.mail.ru/public/83jc/MSstJxrFMЕсли кратко, то musl чаще всего немного быстрее, но разница незначительная.
На самом деле разница может быть значительна. Несколько лет назад игрался с этой библиотекой. Там где нужно выжать всё из ЦПУ, производительность программ для рассчётов, собранных с использованием привычной glibc, была в 1.5-2 раза БЫСТРЕЕ чем c musl.Ещё, во времена тех экспериментов приятно удивил clang, но то другая история.
В любом случае проект примечательный — статически собранный файл на базе alpine c musl весил в 20-40 раз меньше аналогичного на glibc. Хочется надеятся, что вся эта экономия не за счёт ассемблерных инструкций, позволяющих добиться максимальной производительности от железа.
> В любом случае проект примечательный — статически собранный файл на базе alpine
> c musl весил в 20-40 раз меньше аналогичного на glibc. Хочется
> надеятся, что вся эта экономия не за счёт ассемблерных инструкций, позволяющих
> добиться максимальной производительности от железа.Основная проблема в удалении "мёртвого" кода линкером. Даже при LTO не всегда возможно определить участки кода, которые при статическом связывании не вызываются. Что бы упростить задачу линкеру, иногда приходится принимать меры в библиотечном коде или вводить условную трансляцию. При создании glibc не ставится цель уменьшить размер исполняемого файла -- там надо, что бы любой школьник мог подгрузить руткит при помощи LD_PRELOAD.