| 1.1, Аноним (1), 16:15, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> такие как FDO (Feedback Directed Optimization), LTO (Link Time Optimization) и PGO (Profile Guided Optimization)
А разве PGO и FDO это не одно и то же?
| | |
| 1.3, kravich (ok), 16:19, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
Как приятно читать такие новости в наши темные времена десктопного софта на базе веб-технологий и нормализации практики вайбкодинга...
| | |
| |
| 2.8, Аноним (8), 16:34, 12/02/2026 [^] [^^] [^^^] [ответить]
| +4 +/– |
Тебе сейчас напишут, что им ИИшечка такие места сразу пишет правильно... а вот диды...
| | |
|
| 1.4, Rev (ok), 16:23, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
То есть до сих пор обработка была ЗАМЕДЛЕНА на 12%?
А в Си нет директивы инлайнинга?
| | |
| |
| |
| 3.14, Аноним (14), 16:45, 12/02/2026 [^] [^^] [^^^] [ответить]
| –3 +/– |
Только сейчас.
До этого код был замедлен на 12%
Возможно программистам-предшественникам было просто класть на производительность.
| | |
| |
| |
| 5.44, Аноним (44), 19:43, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Стогигабитные сети в бэкбоне уже дай бог лет десять или около того используются.
| | |
|
|
| |
| 4.20, Рулона Боева (?), 17:00, 12/02/2026 [^] [^^] [^^^] [ответить]
| +5 +/– |
Потому что инлайнинг функций — это всегда компромисс между экономией инструкций на ее вызов (условно убираем push/call/pop) и итоговым размером объектных файлов, так как тело функции будет дублироваться в каждой функции, которая вызывает встраиваемую.
| | |
| |
| 5.24, ананим.orig (?), 17:25, 12/02/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
А если в коде будет ошибка, то она размножится соответствующее количество раз.
И пока её обнаружат фронт атак тоже увеличится.
| | |
| |
| 6.33, анон (?), 18:11, 12/02/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А если в коде будет ошибка, то она размножится соответствующее количество раз.
> И пока её обнаружат фронт атак тоже увеличится.
Чего-чего? Какой фронт, какое "размножится"? 🤦
Инлайн, это
замена "вызов_кода_с_ошибкой" на "копия кода с ошибкай", т.е. что совой о пень, что пнем о сову ...
| | |
|
|
|
| 3.26, Rev (ok), 17:36, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Не понял. Сейчас установлена? Но пишут же, что вручную заинлайнили. Я так это понял, что код функции перенесли туда, где он используется, избавившись от вызова функции.
| | |
| |
| 4.28, Совершенно другой аноним (?), 17:47, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Не понял. Сейчас установлена? Но пишут же, что вручную заинлайнили. Я так
> это понял, что код функции перенесли туда, где он используется, избавившись
> от вызова функции.
посмотрите patch, ссылка на него есть в тексте новости. Если по-простому, то функции перенесли из файла *.c в файл *.h и дописали static inline.
| | |
|
|
| 2.29, ___ (??), 17:48, 12/02/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
в сетях 100 мбит и процент замедления скорее всего был гораздо меньше, так как частота пакетов была меньше
| | |
|
| 1.7, Аноним (7), 16:34, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Жаль только, что тспу очень агрятся на юдп. Но, что-нибудь обязательно будет придумано!
| | |
| |
| |
| 3.11, Аноним (7), 16:40, 12/02/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Повезло с провайдером. Видимо ещё активное оборудование не шибко внедрили.
| | |
| |
| 4.13, 12yoexpert (ok), 16:43, 12/02/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
а модем мой пассивный, по-твоему? и как ты собрался внедрять какое-то оборудование ко мне в мобилку? у меня два провайдера, ни один мне ни о каких внедрениях не сообщал
| | |
| |
| 5.15, Аноним (7), 16:47, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Я думал, что там у них есть два класса оборудования и стоит оно до Ваших модемов. Ну да ладно. Главное, что Вам нравится!
| | |
| 5.16, Аноним (16), 16:48, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> и как ты собрался внедрять какое-то оборудование ко мне в мобилку?
Легко. Одним законом о предустановке российского ПО. Если тспу понадобятся сразу на уровне каждого смартфона.
| | |
| |
| 6.60, 12yoexpert (ok), 01:17, 13/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
зачем кому-то может понадобиться вводить законы о предустановке российского ПО? и кто этому кому-то позволит это сделать?
| | |
|
|
|
|
| 2.34, Аноним (34), 18:24, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– | |
да, хорошая новость, буст в 12% при обработке udp пакетов на тспу это прям приятно!
надо потесть, действительно ли есть прироста и если есть, то можно сказать что запилили новую фичу, для работы которой нужно ядро 7.0 и выше, и получить за это премию!
| | |
| |
| 3.58, Аноним83 (?), 22:01, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
В ТСПУ скорее всего DPDK или около того, ему на эту оптимизацию параллельно.
| | |
|
|
| 1.10, timur.davletshin (ok), 16:39, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
К пользовательским реализациям никакого отношения не имеет. Там ни разу ничего не упиралось в производительность timecounter_cyc2time().
| | |
| 1.12, Аноним (14), 16:41, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
Миф "о невероятно оптимизированном дидовом коде" развеян.
В который раз))
Кто бы мог подумать, что аффторы оригинального кода не знали о возможности инлайна.
| | |
| |
| 2.17, Аноним (17), 16:52, 12/02/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
а причем тут дидовый код, у вас ведь компиляхтор "луДше" код генерит.
| | |
| 2.38, Аноним83 (?), 19:07, 12/02/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Дидам никогда не нужно было знать точное время получения UDP пакета, всё как то без этого прекрасно работало.
| | |
| |
| 3.46, Аноним (44), 19:56, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Оно и понятно почему. Все данные умещались на СЕРВЕР-1 с репликацией на СЕРВЕР-2, а оттуда -- на ленту, но только если сегодня робот работает (а не обслуживается вендором). Можно и время не знать, и вручную админить, и даже выучить наизусть оба айпишника (и специально выбрать "красивые", чтобы легче было запоминать). С тех пор многое поменялось, без синхронизации времени и точных временных меток событий современный энтерпрайз не работает.
| | |
| |
| 4.48, Аноним83 (?), 20:04, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Всё прекрасно работает, и работало.
Не смотрел код NTP клиентов/серверов, но думаю и там разница между временем получения пакета ядром и временем когда приложение его вычитало из сокета не такое значительное.
И уж точно не стоял вопрос того что опция сохранения времени ядром частоиспользуемая/заметная на общем фоне, просто никто столько не пулял, даже на тех слабых железках.
Для остального был TCP, полностью ядерный, который и вылизывали. И эти самые тайминги там и использовались в CC, хотя тоже вроде не так интенсивно.
Ниже я расписал откуда эта дичь вылезла.
| | |
|
|
|
| 1.27, Cyber100 (ok), 17:43, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
не могу сосчитать без логарифмической линейки и штангенциркуля == если у них на 100гб канале все увеличилось аж на 12%, значит, на 1 гб канале - это будет 1200% или наоборот 0,12%?
| | |
| 1.31, Аноним (31), 18:00, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> В данной ситуации автоматические применяемые компилятором оптимизации, такие как FDO (Feedback Directed Optimization), LTO (Link Time Optimization) и PGO (Profile Guided Optimization), не смогли обнаружить горячий сегмент кода и проигнорировали его,
А Боромир.. А компилятор Rust'a сам бы всё заинлайинл!
| | |
| |
| 2.39, Фамилия (?), 19:15, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
То есть, вы хотите сказать, что этот магический компилятор магически видит горячие сегменты кода и магически понимает, что тем людям, которые это дело компилируют надо именно заинлаинить этот кусок кода в угоду производительности на каком-то конкретном тесте? Просто вау. А почему же тогда никто и нигде про эти магические способности не говорит? Это же такая классная реклама! Компилятор, который генерит безопасный код, ещё и знает заранее всё то, что вы и сами ещё пока даже не знаете!
| | |
| |
| 3.51, Аноним (51), 20:19, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ну, справедливости и логики ради, можно придумать и ситуации, когда компилятор и мог бы что-то понять и без магии. Например. Есть функция с передаваемыми параметрами. Небольшая по кол-ву генерируемых команд. И вызывается в программе в трех-четырех местах и два из них - внутри циклов. Почему бы не заинлайнить код не вызывая функцию? Никакой магии, да и наверное даже спец. флажков компилятора, для такого не надо. Вызов небольшой функции внутри цикла - очень вероятный кандидат на горячий сегмент кода.
| | |
| |
| 4.52, Фамилия (?), 20:39, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Компилятор да, делает оценки и решает надо ли заинлайнить какую-то функцию или нет (при условии присутствия нужных флагов).
Но инлайн-инлайну рознь. Где-то инлайн может дать преимущество, а где-то наоборот. Где-то кэши уместили в себе все заинлаиненные вещи, а где-то не уместили и будет происходить деградация производительности.
Компилятор сам по себе не может в общем случае понять, является ли данный сегмент кода горячим.
Если бы такое было возможным, то JVM тогда могла бы все горячие функции откомпилировать заранее и стать быстрее Си. Но этого не происходит, а происходит обратное - JVM сначала запускает код и смотрит, а что становится горячим. Что стало, то и оптимизирует.
Здесь получилась та же ситуация. Люди запустили и обратили свой взор на конкретное место. Увидев горячее место, провели оптимизацию и получили выигрышь. Это обычный рабочий момент, не надо в нём искать какой-то негатив по отношению того, что авторы используют устаревшие технологии, и что надо просто перейти на новые технологии и всё само станет быстрым и шелковистым.
Вот, например: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannku . Никто с первого раза не написал программу так, чтобы она работала на каком-то классе тестов очень быстро.
| | |
|
|
|
| 1.37, Аноним83 (?), 19:06, 12/02/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Отмечается, что функция timecounter_cyc2time() может вызываться на каждый входящий пакет, поскольку современные протоколы требуют учёта времени поступления пакета.
Кто не понял, поясню: они накостылили http/2 / quick, где им пришлось в юзерспейсе имплементировать cognestion control алгоритмы, для работы которых потребовалось включать опцию для записи времени получения пакета.
SO_TIMESTAMP / SO_TS_CLOCK / SO_TIMESTAMPNS.
До этого данная опция почти никогда не применялась при работе с UDP ибо нафиг не надо знать время когда пакет пришёл. В худьшем случае в event обработчике чтения в самом начале получали время и считали что все пакеты прочитанные за этот цикл приёма из сокета были получены в это время.
Иными словами:
1. Для обычных приложений от этой оптимизации толку 0.
2. Сами себе придумали проблему с quick (юзерспейс TCP) - сами преодолевают.
| | |
| |
| 2.53, morphe (?), 20:54, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Сами себе придумали проблему с quick (юзерспейс TCP)
Скорее SCTP, у QUIC есть преимущества над просто TCP для многих задач, как минимум возможность слать датаграммы по тому же каналу (Про URG флаг TCP говорить не надо, пользоваться им тем более, пусть он умрёт вместе с FTP)
| | |
| |
| 3.57, Аноним83 (?), 21:59, 12/02/2026 [^] [^^] [^^^] [ответить]
| +/– |
Нет.
В документации написано: socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
IPPROTO_SCTP != IPPROTO_UDP.
Не встречал софт где юзалось TCP URG, да и в целом не вижу с этим проблем - открыть ещё одно TCP соединение.
| | |
|
|
|