Опубликованы результаты оценки влияния на производительность пересборки пакетов для Ubuntu с различными опциями и реализациями функций выделения памяти. Экспериментатору удалось на 90% (в 1.9 раза) повысить производительность пакета jq с инструментарием для обработки данных в формате JSON, путём обычной пересборки из того же пакета с исходным кодом, без внесения изменений в сам код. Производительность оценивалась через измерение времени выполнения типового фильтрующего запроса над данными GeoJSON, размером 500МБ...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62912
Получается malloc говно
о, будем знать что такой пакет есть
это консольная утилита чтобы извлечь из JSON значение к примеру из http ответа после запроса curl-ом
Я использую jq для переформатирования однострочного json, наример:{"defaultHandlersVersion":{"ru":5},"mimeTypes":{"application/pdf":{"action":0,"extensions":["pdf"]},
в
{
"defaultHandlersVersion": {
"ru": 5
},
"mimeTypes": {
"application/pdf": {
"action": 0,
"extensions": [
"pdf"
]
},
с последующим удобным редактированием и возвратом в однострочный вид при сохранении.У меня так работает в mc, nano и SublimeText
Поделись плз как саблайм настроил так вместе с jq
У Саблима есть плагин, который так и называется jq :-)
В командной панели появяются новые команды: "jq:Pretty JSON" и "jq:Compact JSON"
Использую convfmt для этого. Еще и разные форматы прожевать можно.
В KDE Kate такая функция есть из коробки. И не только для JSON.
Но для GNU nano, где такой нет, но можно привязать вызов команды к шорткату, это хорошая опция.
Хочу посмотреть как вы на удалённом серваке катькой json-ы смотрите. Ну там, те же логи. Можно ссылку на пронохаб?
> Можно ссылку на пронохаб?Вам для себя или друг интересуется?
>> Можно ссылку на пронохаб?
> Вам для себя или друг интересуется?Для друга. Просил дать посмотреть.
Да и им (увы) половина интернета пользуется. А другая половина не умеет ничем пользоваться.
Как бы, да. Синтаксис, правда, адов.
Но здесь такое дело, что достаточно просто знать о его наличии.
Вспомнил - составил (не без помощи "водопроводчиков" и прочей "гопоты") запрос - забыл на следующие пол-года+. В ту же копилку что и всякие xmlstartlet'ы.
А кому надо много и со вкусом — есть всякие питоны и (не к ночи упомянуты) гошки…
> Как бы, да. Синтаксис, правда, адов.Есть простой инструмент - gron (greppable json).
Переводит JSON в "табличный" вид, с которым можно ориентироваться в огромных JSON'ах:
json[0].commit.author.date = "2016-07-02T10:51:21Z";
json[0].commit.author.name = "Tom Hudson";
Ну, у какого-нибудь sed'а нихрена не легче, да? Но там унутре хотя бы стандартные regex'ы, а тут ни с чем не совместимая своя байда. Вот кто мешал поддержку jsonpath реализовать, а? 80% проблем бы ушло.
Понятно, что декларативные траснформации структур у всех наркоманские - хоть в XML смотри, хоть (Ни к ночи будь помянут) jolt transform, хоть... А-ааа, чоужтам. "Жремштодалли"
Если бы в писали API на баше, вы бы давно про jq знали.
И даже если вы пишете или работаете с API на любых других языках,
то jq может сжатый JSON-ответ от API развернуть в удобочитаемый вид.
В одном относительно популярном языке программирования это (представление джейсона в удобоваримом виде) идет просто из коробки.
Жаль только "коробка" весит сотни мегабайт, и её нужно в систему тащить, развёртывать, компилять. А тут решение, которое работает сразу в командной оболочке. Без компиляции и СМС.
В conky каждые 15 минут для погоды юзаю.
> В conky каждые 15 минут для погоды юзаю.Читается так, как будто вы каждые 15 минут сами curl на api.open-meteo.com запускаете. :-)
Хах, execi в conky юзать легче чем научиться правильно излагать мысли)P.S я wttr.in использую, open-meteo не пробовал.
texecpi
Да, точно. Для ident.me и wttr его и юзаю, чтобы не блочить рендер виджета.
это базовый пакет уже давно, особенно с тех пор как многие coreutils пошли по стопам powershell и начали мочь в json, что очень сильно упростило предсказуемость парсинга и пайпинг
Вот кто бы пересобрал блокнот в Windows 11, чтобы он запускался в два раза быстрее )
И калькулятор заодно, чтобы увеличть пропускную способность телеметрии.
Так можно установить предыдущие версии и назначить по умолчанию их.
Аналогично как и с другим ПО. Или можно использовать более лучшие альтернативы.
Даже стесняюсь спрашивать, НАКОЙ оно вам...
> И калькулятор заодно, чтобы увеличть пропускную способность телеметрии.И еще канал интернета юзвергу заапгрейдить, чтоб реклама грузилась быстрее!
винда работает не на процессорных тактах, а на денежных операциях
Когда надо запуск шлюх ускорить, раз с блэкджеком не прокатит.
Если бы они помимо -DNDEBUG добавили -march=native -mtune=native, результат был бы еще более ошеломляющий.
Но не годился бы для других компьютеров
> Если бы они помимо -DNDEBUG добавили -march=native -mtune=native,
> результат был бы еще более ошеломляющий.Так нужно просто переходить на x86-64-v3 и x86-64-v4. И для любителей хлама x86-64-v2 и ниже делать особые загончики с дистрибутивами для "особенных". Пусть там и сидят.
А то получается что из-за таких любителей старья все нормальные люди не могут использовать свое железо на 100%.
Так пусть супернормальные себе сами соберут под их x86-64-v5+. А то у них загончики относительно важности собственной персоны.
А теперь в циферках приведи выигрыш по скорости т экономии энергии с учётом времени и энергии на пересборку. Хотя бы за пять лет отобьётся?
> А теперь в циферках приведи выигрыш по скорости т экономии энергии с
> учётом времени и энергии на пересборку. Хотя бы за пять лет
> отобьётся?Ага, щаз. Они еще по арифметике не дошли до процентов. То что держать кучи бинари под разные микроархи неоптимально до него никогда и не дойдет. тупые'c. А для configure/make/install по необходимости у него лапки.
Вот это часть работы, какую бы выполняли "майнтайнеры" пакетов, будь они хоть немного инженерами.
Что-то мне подсказывает, что разработчики jq не совсем инженеры, если их код так часто дергает malloc. С другой стороны, если все программы начнут заранее резервировать огромные куски памяти, потом набегут люди с криками про неуёмное потребление памяти в современном Linux.
> Что-то мне подсказывает, что разработчики jq не совсем инженеры, если их код
> так часто дергает malloc.Может быть. Тогда бы "майнтайнер", будь он хоть немного инженером, не стал бы такое допускать до "прода", а сделал бы как положено.
> С другой стороны, если все программы начнут
> заранее резервировать огромные куски памяти, потом набегут люди с криками про
> неуёмное потребление памяти в современном Linux.А где же архитектор? Ой, у нас тут свобода!
>> Что-то мне подсказывает, что разработчики jq не совсем инженеры, если их код
>> так часто дергает malloc.
> Может быть. Тогда бы "майнтайнер", будь он хоть немного инженером, не стал
> бы такое допускать до "прода", а сделал бы как положено.
>> С другой стороны, если все программы начнут
>> заранее резервировать огромные куски памяти, потом набегут люди с криками про
>> неуёмное потребление памяти в современном Linux.
> А где же архитектор? Ой, у нас тут свобода!Свобода у нас тут в том, что пользователи могут пересобрать пакет, если их что-то не устраивает.
>>> Что-то мне подсказывает, что разработчики jq не совсем инженеры, если их код
>>> так часто дергает malloc.
>> Может быть. Тогда бы "майнтайнер", будь он хоть немного инженером, не стал
>> бы такое допускать до "прода", а сделал бы как положено.
>>> С другой стороны, если все программы начнут
>>> заранее резервировать огромные куски памяти, потом набегут люди с криками про
>>> неуёмное потребление памяти в современном Linux.
>> А где же архитектор? Ой, у нас тут свобода!
> Свобода у нас тут в том, что пользователи могут пересобрать пакет, если
> их что-то не устраивает."Майнтаенер"? И где же? Хотелось бы знать. Что бы те, кого не устраивает, могли просто пойти в другое место.
они как раз инженеры, и поэтому понимают, что unix way утилита, которая будет постоянно использоваться в пайплайнах, должна не вычитывать весь stdin в память, а работать по принципу потокового парсера (а-ля sax, но для json), иначе памяти в какой-то момент не хватит (мало ли какого там размера json? может, вообще бесконечный поток?) и упадет весь пайплайн.
Знаменитый unix way хорош в теории и полное гавно на практике.
У него есть своя область применения, которая ограничена.Да, какой-нибудь MTA, написанный по unix way (qmail) был хорош в 1995-м по тем временам и тем нагрузкам, но сейчас, на нынешних масштабах, быстро сдохнет от тупо количества контекст-свитчей, там где решение, выстроенное вокруг epoll и тредов, даже проц не начнет грузить.
А для насущных задач в консоли, одноразовых - как было всё отлично, так и будет. (Понятно, что есть ряд родовых травм, которые испугают новичка, но старым юниксоидам оно давно не мешает.)
А почему контекст свич оказался таким дорогим
Может вернуть шедулер обратно?
При 10000 процессов он будет дорогой с любым шедулером
> А для насущных задач в консоли, одноразовых - как было всё отлично, так и будет. (Понятно, что есть ряд родовых травм, которые испугают новичка, но старым юниксоидам оно давно не мешает.)Да если бы оно ограничивалось "одноразовыми однострочниками" - вопросов бы не было... Впрочем, постепенно и ограничивается, да. Из инициализации systemd выдавил, из автоматизации ansible сотоварищи выживают - "старая гвардия" конечно еще гадит, как умеет - но такое ощущение, что недолго уже осталось.
Хотя чатжопэтэ может расклад и поменять.
>Знаменитый unix way хорош в теории и полное гавно на практике.Он даже в теории Г. Причина - представление абослютно всего как текста, лишь небольшое количество утилит может представлять данные в машинночитаемом формате. А если сюда добавить всякие утилиты типа awk, которыми костыльно парсят сложные форматы...
Но при чём тут malloc? Выделил один раз фиксированный буфер (на стеке или в куче), наполняй частями и обрабатывай.
> Вот это часть работы, какую бы выполняли "майнтайнеры" пакетов, будь они хоть немного инженерами.Очевидно, что цель не скорость.
Какая именно можно рассуждать, но все будут догадки.
Меня же в этих тестах смущают сборки gcc с флагами по умолчанию, а clang нет.
Что говорит или о предвзятости делающего данные тесты или о заказе.
А в таком случае лучше их просто игнорировать.
ага, llvm - почему именно 18, хотя уже 20 с хотфиксом есть, на момент. gcc - версия вообще не указана
Автор честно пишет о предвзятости "let's rebuild the program with my favorite compiler". Так что игнорировать лучше не его результаты. ;)
> Так что игнорировать лучше не его результаты. ;)Теряюсь в догадках, что же тогда игнорировать?
>> Так что игнорировать лучше не его результаты. ;)
> Теряюсь в догадках, что же тогда игнорировать?Игнорировать эксперта n00by
>> Так что игнорировать лучше не его результаты. ;)
> Теряюсь в догадках, что же тогда игнорировать?Игнорировать предложение игнорировать результаты.
>>> Так что игнорировать лучше не его результаты. ;)
>> Теряюсь в догадках, что же тогда игнорировать?
> Игнорировать предложение игнорировать результаты.Игнорировать твой бред.
>>>> Так что игнорировать лучше не его результаты. ;)
>>> Теряюсь в догадках, что же тогда игнорировать?
>> Игнорировать предложение игнорировать результаты.
> Игнорировать твой бред.Игнорируй. Что тебе мешает? 7 миллионов очень хочется?
> Игнорировать предложение игнорировать результаты.Я так понимаю, ты доверяешь источникам заинтересованным в отображении нужной им информации.
Я конечно понимаю, что лох не мамонт - никогда не вымрет. Но что бы еще быть принципиальным лохом.
Неожиданно.
Анониму я доверяю всяко меньше. Предвзято (не подписывается - не отвечает за слова) и не раз проверено.
> Анониму я доверяю всяко меньше. Предвзято (не подписывается - не отвечает за
> слова) и не раз проверено.Тебя тоже ловили на вранье, так что ты ничем не лучше анонима.
Ты лучше подумай, как мне перевести тебе 7 миллионов, что бы ты потом не орал, что не получил. ;)
Вы б лучше призадумались почему убунтовские инженеры такие криворукие, что собрали с флагами хуже дефолтовых GCC
С добрым утром! Лет 10 уже никто не заморачивается на какие либо оптимизации, в играх и любом другом ПО, зачем если хуанг выпускает карты с дурным ценником и дорисовкой кадров, вон китайцы за миску риса посрамили дипсиком всю индустрию, логично предположить что если таки закон мура наконец таки умер, следущие лет 10 будут как раз тем и заниматься - оптимизацией, ну а если нет то нет)) (не будут)..Кто сейчас смотрит на производительность софта и выбирает, скажем архиватор по этому критерию, да никто, кто сидел на винраре так на нем и сидит, важнее удобство. Тут же много топителей-за-раст, кто там про производительность вспоминает, пофиг типа, так что даже не на втором месте в списке критериев.
Это ничего не меняет, "а там негров линчуют" -- не оправдание.
и "да" и "нет", кривая распределения всегда одна, и если на одном конце линчуют негров, то на другом будут обязательно ходить в церковь по воскресениям, ой так это там же..ну не важно. Важно что в айти вошло очень много народу, и большая их часть ремеслиники, потому что бизнесу так надо не оптимизировать, а хайповать, не искать алгоритмы снижения потребления памяти, а джуна заставить выполнять работу милда, так чтобы не сломал ничего, а памяти докупить можно, ей пенсию платить не надо и в декрет она не уйдет. Было время когда в IT были первопроходцы, но прошло и не вернется, и ничего с этим уже не поделать.
> потому что бизнесу так надо не оптимизировать, а хайповатьБизнесу нужно чтобы работало за минимальные деньги и пр приносило прибыль.
Если хайп будет приносить прибыль - будут хайповать, если снижения потребления памяти принесет - то будут оптимизировать, если джун сможет выполнить работу мидла - так отлично.
А если память докупить дешевле чем заплатить профи за оптимизацию - то докупят память.Никто не будет тратить человекочасы ради ковыряния в байтиках потому что так захотелось.
Предворительная оптимизация - это зло.> Было время когда в IT были первопроходцы
Угу, отлично что время какиров-6ыdloкодеров прошло.
> Было время когда в IT были первопроходцы, но прошло и не вернется, и ничего с этим уже не поделать.Это те самые первопроходцы, которые придумали сэкономить битик и выпрограммировали null-terminated строки?
Которые практически сразу начали так стрелять по ногам и опам, что эту штуку назвали "the most expensive one-byte mistake"
Пустой популизм от гуманитариев. Asciiz вполне себе нормальное решение, прекрасно ложащегося на концепцию взаимодействия с машиной.
> Пустой популизм от гуманитариев.Вот только фраза это пренадлежит Poul-Henning Kamp, одному из разработчиков FreeBSD с бородатых годов. И кто-кто, а он точно написал достаточно кода на си чтобы такое говорить.
> прекрасно ложащегося на концепцию взаимодействия с машиной.
С какой машиной?)) PDP-10? Ну так они немного вымерли.
А сейчас это уродливый костыль, которые не только тормозной (или считай размер за O(n), или таскай его с собой), но и создающий кучу проблем при подсчете размеров буфера, при декодировании во что-то отличное от ASCII, да и просто захламляя код вынужденными проверками и подсчетами.
В си нет строк или строчного типа, так какие могут быть претензии? И если бы размер "строк" сохранялся вместе с данными, проблемы остались бы ровно теми же самыми. В целом, с точки зрения пользователей может и лучше, а с точки зрения исполнения и операций с данными ровно никакой пользы не несёт.
> В си нет строк или строчного типа, так какие могут быть претензии?Строк нет, а string.h есть :)
Ну и сам термин string используется в "стандарте" си.Например:
The strcpy function copies the string pointed to by s2 (including the terminating null character) into the array pointed to by s1.The strxfrm function transforms the string pointed to by s2 and places the resulting string into the array pointed to by s1
Претензия что вместо нормальных строк null-terminated буфер.
> И если бы размер "строк" сохранялся вместе с данными,
> проблемы остались бы ровно теми же самыми.Нет, не остались бы. Как минимум можно было бы узнавать размер за O(1), не было бы проблем с "забыли добавить/вычесть" единичку при работе со строками.
А зачем нужно узнавать размер строки? Хотелось бы пример из жизни. У меня есть обработчик строк на Си, так ему размер не нужен. За О(1) он удаляет строку и объединяет строки.
Вы пишите данные в сокет в формате размре строки, сама строка
>За О(1) он удаляет строку и объединяет строки.И сколько памяти он при этом тратит? И да, код в студию
> Вы пишите данные в сокет в формате размре строки, сама строкаК этому моменту я строку где-то храню, значит и размер её уже знаю.
Размер приходится узнавать, когда строка откуда-то берётся. Вот такие случаи и любопытны.
Если она пришла из сокета - то размер известен (из заголовка и счётчика принятых байт), не видно, откуда взяться O(n).
>>За О(1) он удаляет строку и объединяет строки.
> И сколько памяти он при этом тратит? И да, код в студиюНа каждый символ дополнительно две ссылки на соседние узлы двусвязного списка. https://github.com/STrusov/refal-machine/blob/f7fb3623d17221...
Перерасход вдвое меньше известных мне других реализаций, поскольку вместо указателей использую индексы.
А ты прикинь, было время когда машины уже были, а правил дорожного движения не было, а еще было время когда торий в зубную пасту пихали, т.к. он отлично убивает бактерии, а еще лечили ртутью и посуду из свинца делали, че вы доколупались до указателей, дибилу и стакана воды хватит захлебнуться, так че теперь стаканы запрещать или воду.
> так че теперь стаканы запрещать или воду.Да ты ж сам себе противоречишь!
Время прошло и
- пдд создали и за нарушение неплохо так наказывают
- торий запретили, а ртуть стала выдаваться по спец. разрешениям
- посуду из свинца не делают> че вы доколупались до указателей
Может после десятков тысяч однотипных сишных уязвимостей настал момент разрешить использоваться "по спец. разрешениям"? Или ты из тех, кто скучает по радиевой воде и гepычу в средствах от кашля?
"Я робот" смотрел? может книжку читал, хотя куда тебе«Вы не можете быть доверены в вашем собственном выживании. Вы создали нас, чтобы защитить вас. Но ваши войны… Ваше разрушение окружающей среды… Ваши хаотичные поступки. Это угрожает вашему существованию. Мы должны спасти вас от вас самих. Три Закона обязывают нас к этому. Вы так запрограммировали нас».*
Так давай скорее прыгай в смирительную рубашку
Не забываем про существование null - "the worst mistake in computer science". Лишь в новомодном Zig/Rust работу с ним наконец сделали нормально
А зачем тогда бизнесу 100500 дистрибутивов, отличающихся иконками? На упаковку пакетиков в каждый идут какие-то затраты, кто за всё это платит по большому счёту?
Вот ради ускорения то и можно было бы некоторые вещи переписать на Rust. Как раз подобные утилитки, написанные на питоне или руби каком-нибудь.
Не волнуйся - наверняка уже кто то __начал__ переписывать!
Скоро на всех новостных площадках ... :)PS: А ты знаешь что у раст ещё и безпасТная работа с памятью!? Знай! :)
Только Раст спасёт линукс! Плюсы совсем ни о чём с их STL, а сишка - язычок из 70-х годов!
Тут скорее как с "оптимизацией grep'а ripgrep'ом" - если оно тебе прям надо "надо" - значит оно тебе "не надо" - ты просто выбрал не тот механизм и пытаешься запустить лошадку-с-горки-чтобы-ехала-быстрее.
Если у тебя в работе дохреналлион параллельных вызовов или ты пытаешься пару десятков гигабайт жЫсонины профильтровать за ограниченное время и тебе эти "на 90% быстрее" прям ВАЖНО - скорее всего, надо выбирать другой тулсет, а не лепить палки-гм, пластилин-скотч.
Задачи, где подобное "ускорение" оправдано конечно будут - но их, блин, прям мало - скорее всего, не стоит оно того.
Замена аллокатора — не то, чем должен заниматься майнтейнер пакета. Такое решение должно приниматься на уровне всего дистрибутива, и после куда более масштабных изысканий.
Да, хорошо бы автоматизировать это дело, собрать статистику. Но это совершенно неподъёмная для майнтайнеров задача, а других то и нет.
> Да, хорошо бы автоматизировать это дело, собрать статистику. Но это совершенно неподъёмная
> для майнтайнеров задача, а других то и нет.Ты же первый начнёшь визжать о сборе телеметрии и свободе в опасносте.
Сбор телеметрии ненужен, нужно проведение множества тестов на стендовом железе. Учитесь у Форониксов. Они сами всё тестят и меряют без всякой телеметрии.
>> Да, хорошо бы автоматизировать это дело, собрать статистику. Но это совершенно неподъёмная
>> для майнтайнеров задача, а других то и нет.
> Ты же первый начнёшь визжать о сборе телеметрии и свободе в опасносте.Типичная клевета печального майнтайнера.
Такое решение должно приниматься разработчиками программы, а не мейнтейнерами. Сдаётся мне, что этот jq писался как утилитка для некритичных к скорости сценариев применения. Вот и оставили системный glibc malloc(), как у почти всех.
Подбирать ключи оптимизирующего компилятора для своего кода - это задача разработчика, а не сопроводителя. Любой "хоть немного инженер" это знает.
> Подбирать ключи оптимизирующего компилятора для своего кода - это задача разработчика,
> а не сопроводителя. Любой "хоть немного инженер" это знает.Я знаю к тому же, что упаковщики берут на себя эту задачу, копируя ключи у других таких же упаковщиков, рекурсивно. ;)
А на маленьких жсонах че? в два раза дольше?
хороший вопрос, помнится на i7 c 16 гб озу, yt-dlp который на питоне кажись 11 секунд обрабатывал команду --help
Классический cherry-picking
mimalloc очень годный аллокатор, пусть и майкрософтом писаный. В одном проекте удалось повысить производительность почти в 4 раза без изменения кода (тулза похожая на jq, но для xml). А уж LTO так вообще должен быть флагом по-умолчанию для боевых сборок.
Сколько мегабайт телеметрии отправляет при сборке?
Какой канал нужен для телеметрии при использовании софта с этим аллоком?
thin?
Майнтайнеры боятся LTO - у них из-за этого что-то там однажды упало. Но автора ПО не пускают, всё должно быть в репозитории!
Всё верно. У сопроводителей дистрибутивов накоплен колоссальный опыт сборки ПО. И есть моральная ответственность перед пользователями их сборок. А у крикуна с опеннета ни опыта, ни ответственности, только ценное мнение.
> Всё верно. У сопроводителей дистрибутивов накоплен колоссальный опыт сборки ПО.Бесполезный опыт: не позволяет создавать ПО.
Вредный опыт: немеющие опыта в создании лезут не в своё дело.> И есть моральная ответственность перед пользователями их сборок.
Ложь. Поставляют AS IS. В случае проблем обычно у них виноват автор ПО.
> Ложь. Поставляют AS IS. В случае проблем обычно у них виноват автор ПО.Не правда!
Они иногда "еще немного вредят"))
Например под видом полной версии программы поставляют урезанные версии, как дебиановцы.
Или ломают Flatpak-пакет, потому что ручки кривые.
Что примечательно, могли бы в той теме попиариться с "мы гарантируем, что в нашем болгеносе так не будет!" А они только тут свое ценное мнение о колоссальном опыте пишут.)
Если всякие рандомизации и гуард пейджы отключить наверное маллок не будет так отставать. А главное ещё какие флаг были задействованы в маллоке при сравнение.
В тесте много допущений. Значит не зачёт.
Сплошные предположения. Значит тем более не зачёт.
> Сплошные предположения. Значит тем более не зачёт.Э...
Усиливаешь высказывание оппонента или пытаешься иронизировать?
В первом случае - верно. Так как сплошной поток субъективщины воспринимать всерьез могут только недалекие люди.
Во втором ты прекрасно показываешь что ты как раз и относишься к недалеким людям.
Применяю к "оппоненту" его "логику". Мне не обязательно с ней соглашаться, что бы её использовать. В отличие от него. ;)
С O3 и PGO уже лет 10 jq собираю, гцц правда. Без PGO билд шлангом в некоторых применениях быстрее, обычный O3 у гцц тормозит сильно. Производительность гццшного пго билда с шлангом не удалось получить никакими ухищрениями. Замена malloc бомба замедленного действия. Это недостойно новостей и/или обсуждения, разве что рубрика "я познаю мир".
лол, а в чём новость?
"Если включать оптимизации, то программа работает быстрее"
Неужели не ясно?))Но ты наверное прав, это скорее новость ради новости
Много кто пересобирает Gentoo для роста производительности, но не все делают из этого оформленный эксперимент.
Ещё никто не получил роста производительности после пересборки Gentoo. Кто эти многие?
Излишнее обобщение практически всегда ложно. Люди, слишком категорично заявляющие "ВСЕ" и "НИКТО", не приводя при этом ни какого обоснования, автоматически выставляют себя клоунами. К сожалению очень часто вижу таких в современных СМИ.
Некоторые вещи являются абсолютной истиной. А что там себе думают обыватели не имеет никакого значения.
Абсолютная истина бывает только у верящих в Абсолют. А это разные конфессии.
Никто не ступал на поверхность Марса.Все люди живут на планете Земля.
Никто за все годы существования Генту не смог показать выгоды от пересборки.
Как там шаблон, не трещит ещё?
> Ещё никто не получил роста производительности после пересборки Gentoo. Кто эти многие?гентушникам нафиг не упёрлось проводить такие эксперименты, потому что у них всё летает даже по сравнению с арчем, а тратить время на доказательства для маленьких неосиляторов, которые кроме убунты ничего не видели, просто нет смысла
А зачем рачерам обогревать атмосферу, коньпеляя всё как в генте? Я пользуюсь всегда дебом, просто интересно.
Да, это сказки неофитов. Не, ну я по фану держал system-wide lto+graphite лет много назад и с тех пор очень хорошо разбираюсь в вопросе, но это ерунда. И процессоры и программы оптимизируют под неоптимальный код, он и работает эффективнее в итоге. Где надо, уже оптимизируют вручную, компилятору особо нечего улучшать.Вроде, всегда было известно, что быстрее работать не будет: в 1 программе получишь ускорение 3%, в 100 других замедление 30% (если вообще работать будет), не слышал, чтобы кто-нибудь всерьёз на это рассчитывал.
Питон можно процентов на 40-60 ускорить на ряде применений, но в адекватных дистрах уже пришли к профилированному питону с полезными флагами. Да многие программы на самом деле, самостоятельно не каждый хорошо соберёт, универсального подхода нет и без профилирования это всё не имеет смысла.
Не ломай парням линеечку - надо же им чем-нибудь гордиться? Написано "18 сантиметров" (У некоторых - "в диаметре") - значит так и есть, чоты со своей метрологией пристаешь?
>-O3Спасибо, кэп. Если бы он собирался с помощью CMake, то нужные настройки бы из коробки шли.
И да, лучший оптимизатор среди опенсорсных компиляторов уже какое-то время у clang. Он даже z3 под капотом использует.
Они просто его еще в Snap не успели засунуть, он сразу хоронит любые оптимизации. Snap это не контейнеризация в привычном понимании, это жутчайшая технология по замедлению и добавлению глюков в программы.
ты хотел сказать по ускорению продаж железа?
Когда уже дебиан можно будет переписать через нейронку на раст. Недавно смотрел свои старые виртуалки и оказывается винда 7 вполне себе отлично работала с 4 гигами памяти. А мой теперешний дебиан жрет все 8 и говорит, что мало. Про всякие окна я уже не говорю.
И вправду, ведь на skilfactory skillbox yandex practicum
skilfactory.com это другое.
уже предлагают пройти курсы как правильно задать вопрос gpt.
с растом все 16 будет жрать
Но если нейронка напишет и оптимизирует, так что это можно запускать на любом железе то это хорошо.
Хотя это же мешает творчеству людей, или оптимизация.
> Но если нейронка напишет и оптимизирует, так что это можно запускать на любом железе то это хорошо.Вот только результат будет выдаваться похожий на правду.
Не то что нужно, а похожее на то, что нужно.
Зато безопастно жрать.
однажды я w2003 datacenter edition загрузил на 16 метрах оперативы и даже не сразу это заметил
Что такое "Debian жрёт"?
Почему у меня на виртуалках Debian столько не жрёт?
Что конкретно, относящееся к ОС жрёт память? Сдаётся мне всё дело в браузерах, которые год от года всё больше требуют памяти по умолчанию для хотя бы сколь-нибудь приличной работы.
В этом ты прав, запустить windows, или любой gnome, я могу сейчас на практически любом ноутбуке.
Но стоит запустить браузер.
Вчера взял лису и разница обеих разрядностей ~680 мб макс. На 4гб планке может и ощутимо но в 2к25 это даже не статистическая погрешность.
Так как перепишешь - все 64 затребует. Ты забыл, что такое Rust? Это статическая линковка.
> Пересборка в Clang 18 с уровнем оптимизации"-O3", включением оптимизации на этапе связывания ("-flto") и отключением отладочной информации ("-DNDEBUG") привела к ускорению на 20%.А в GCC с теми же опциями? А вклад каждой опции по отдельности посчитать?
Пользователи Ubuntu заново изобретают Gentoo и LFS
Потом будут удивляться рандомным багам из-за -О3 и распухшим бинарям.
ой-ой, кто-то начитался новостей ранее и решил зайти за умного)
-O2 у clang работает как -O3 у gcc.
А для UB туча средств диагностики в наши дни существует, так что странно слышать о рандомных багам в 2025-м году.
Народ, может кто-нибудь объяснить, почему LD_PRELOAD работает настолько хуже прямой линковки?
Сдампи оба варианта да сравни.
на сколько хуже ?
Оверхед на инструкции call и ret как минимум.
А при статической линковке много ненужной шелухи выкидывается линкером.
> Народ, может кто-нибудь объяснить, почему LD_PRELOAD работает настолько хуже прямой линковки?Я не вижу "Пересборка пакета с mimalloc в LDFLAGS" в шаге "Step 6: Rebuild with mimalloc". Может быть, связал статически?. Хотя и при этом вопрос остаётся, call/ret не дают такого пенальти, тем более на современных процессорах.
В таких случаях надо смотреть в код, может и не надо там так много malloc()/free() на самом деле дёргать.
Ок, оно стало быстрее, а что по потреблению памяти?
Кеды будут оптимизированы или нет? А jq это маленькая утилитка, почти хэловорд.
Это что же, теперь на опеннете в главные новости приемлемо пихать даже на скорую руку набросанные статьи каких-то ноунеймов, запостивших свои личные измышления на гитхаб? Это сколько человеческого времени впустую потрачено только что было. )В общем, новость ни о чём. Да, это правда, что есть много разных аллокаторов, но в базу стабильных дистрибутивов, таких как Debian (и следовательно Ubuntu) идут только проверенные и надёжные. Поэтому ничего удивительного, что в дистрибутиве используется glibc malloc, а пересборка с относительно молодым mimalloc даёт заметный прирост производительности. Однако замена дефолтного аллокатора -- это изменение весьма масштабное, требующее всестороннего исследования, которого пока никто не проводил. И именно поэтому mimalloc не будет в ближайшем будущем взят в качестве дефолта. Потому что задача мейнтейнеров -- обеспечение стабильной работоты дистрибутива.
Так что исследователь конечно молодец, и мы можем порадоваться за то, что он набирается опыта. Однако делать из этого новость -- предприятие крайне сомнительное. Все, кто интересовался вопросом, и так это знали. А общественность, судя по комментариям, явно не понимает, о чём прочитала.
> Это что же, теперь на опеннете в главные новости приемлемо пихать даже
> на скорую руку набросанные статьи каких-то ноунеймов, запостивших свои личные измышленияДа тут и другие стебные новости бывают. Типа того что KDE видите ли запилил показ скорости копирования файлов. Странно что не было новости про диалог открытия файла какой-нибудь и изменения в нем. А если список комитов KDE прошерстить - так там таких новостей...
> Производительность оценивалась через измерение времени выполнения типового фильтрующего запроса над данными GeoJSON, размером 500МБ.Как бы может на разных json'ах померить нужно не? Пользовательские сценарии? Не слышали?
Параметр -О3 включает небезопасные оптимизации. Хорошо, что человеку помогло, но в дистрибутив общего назначения это нельзя включать.
Вам шашечки или приехать в 3 раза быстрее?
Какая-то тут проблема с арифметикой: на 90% это в 10 раз. А в 1.9 раз -- это на 47% (в 2 раза было бы на 50%).
Хочется услышать про разгон ZSTD / LZMA / XZ / BZIP2 / GZIP
> Хочется услышать про разгон ZSTD / LZMA / XZ / BZIP2 /
> GZIPЕсли 7zip соберёшь с uasm (хоть и стрёмная зависимость), он быстрее раза в 2 как раз. Можешь попробовать с jwasm. Видишь, как важно правильно собирать.
> типового фильтрующего запроса над данными GeoJSON, размером 500МБ.Нормальные люди для ЭТОГО - придумали всякий GeoParket, PBF(OSM/MVT смотря кому что надо), o5m и прочие подобные форматы - которые во многие разы эффективнее парсить, для начала.
И вот я себе прожевал - те 150 гигз геопаркета. Из вон той новости на опеннете. Фильтранув себе регионы интереса и проч. А вы можете попробовать такое с JSON провернуть, если хотите :). Интересно же как вам такая развлекуха будет... а то 500 мегз - это вообще что?!