The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux 6.8 приняты патчи, ускоряющие TCP, opennews (?), 14-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


137. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 14-Янв-24, 18:06 
Там же, кстати, в тесте рассказано как тестировали, однин из типичных сценариев RPC/сервиса. Конечно, 40% получишь не всегда. Из их же тестов, в условиях нехватки кеша улучшения порядка 1-2 %
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

153. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/
Сообщение от ptr (??), 14-Янв-24, 19:52 
> Из их же тестов, в условиях нехватки кеша улучшения порядка 1-2 %

Именно про это речь и веду. Чем больше кода в userspace, тем скорее не хватит кеша.
С минимальным кодом в neper tcp_rr и 256Mb L3 cache они получили аж до 44.47%. Но с тем же кодом уже на 105Mb L3 cache - не более 5.24%. Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

Ответить | Правка | Наверх | Cообщить модератору

187. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 15-Янв-24, 00:52 
Ты ведёшь речь о том, что кеша точно не хватит. Чувствуешь же зарницу?

> Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

Ну не неси чушь. Видимо, разницу не чувствуешь. Хватит или нет зависит от приложения.

Ответить | Правка | Наверх | Cообщить модератору

195. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 05:23 
> Ну не неси чушь.

Спасибо, что признали свое полное поражение в дискуссии, перейдя на личности

> Хватит или нет зависит от приложения.

Вот именно. Ровно то, что я и написал:
> Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

И это будет в несколько раз большая нагрузка на кеш L3, по сравнению с neper tcp_rr

Ответить | Правка | Наверх | Cообщить модератору

197. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/
Сообщение от Аноним (136), 15-Янв-24, 05:39 
Не, это ровно не то, что ты написал. Приводишь ровно один пример приложения, утверждаешь что на нём ничего хорошего заметно не будет и __обощаешь__ этот пример на все приложения. Вот что конкретно ты делаешь. Оставляя единственный вариант 'оптимизация заметна только при маршрутизации'. И это ахинея. Потому что а) не все gRPC приложения как пишешь выше и даже в твоих условиях нагрузка на кеш будет зависеть от реализации. Самый тупой пример хорошей реализации твоего конкретно gRPC это простое кеширование топ-N ответов что уложит основной горячий след по памяти в жирный кеш. Даже и не в жирный. Да даже вся эта InMemoryDB для прогнозов зайдёт в кеш целиком.
Ответить | Правка | Наверх | Cообщить модератору

201. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 07:36 
> И это ахинея

Еще раз спасибо, что публично признали себя демагогом.

Ответить | Правка | Наверх | Cообщить модератору

202. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 07:55 
> даже вся эта InMemoryDB для прогнозов зайдёт в кеш целиком

Там в примере три или четыре прогноза, так что не в этом проблема. Проблема в мегабайтах кода нескольких десятков нитей с собственным стеком и ворохом создаваемых объектов, включая семафоры, которые только на сериализации и десериализации ProtoBuf уже сожрут любой кеш CPU.
Просто скомпилите этот пример https://learn.microsoft.com/en-us/aspnet/core/tutorials/firs...
Потом грузаните его хотя бы на 32-х ядрах, как делал я. И сами увидите, что кеш CPU вытесняется в userspace полностью.
Можете брокер Кафки поднять на тех же 32-х ядрах и с тем же ProtoBuf. Эффект тот же самый увидите.

> __обощаешь__ этот пример все приложения

Потому что проще него придумать, что-то имеющее хоть какую-то практическую ценность, уже мало реально. Теоретически, можно написать сервис на C + ассемблер, сократив нагрузку на кеш CPU. Но на практике финансировать такую разработку будут только в редчайших случаях, о чем я и указал, приведя в качестве примера разработку маршрутизаторов.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

218. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (136), 15-Янв-24, 14:57 
Это, конечно, хорошо, что знаешь столько умных слов, но попробуй всё же услышать что тебе пишут: натягиваешь свой единственный пример на все случаи жизни. Не понимаю в чём проблема понять такую простую и очевидную истину.

> Tutorial: Create a web API with ASP.NET Core

Это даже не смешно ... Затрудняюсь даже прокомментировать такой уровень глупости

> Но на практике финансировать такую разработку будут только в редчайших случаях,

Сервисы на c++ пишут повсеместно, в частности с gRPC и другими RPC

> ... о чем я и указал, приведя в качестве примера разработку маршрутизаторов.

Код, задействованный для маршрутизации, не тот же самый код, который используется в реализации TCP сокетов. Этот патч вообще никак не пересекается с маршрутизацией, он целиком для приложений.

Ответить | Правка | Наверх | Cообщить модератору

232. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 15-Янв-24, 23:30 
> такой уровень глупости

Комментарии излишни )))
Вы уже трижды доказали, что Вы демагог!

Ответить | Правка | Наверх | Cообщить модератору

233. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (233), 16-Янв-24, 00:20 
>> такой уровень глупости
> Комментарии излишни )))
> Вы уже трижды доказали, что Вы демагог!

По моему ржать тут стоит с додика с доднетом который ему видите ли кеш вытеснил. Бжа, это вы там с майкрософтом отношайтесь на эту тему. Тут вы что забыли? Вам с сабжа вообще нихрена не обломится.

Ответить | Правка | Наверх | Cообщить модератору

296. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 19-Янв-24, 03:43 
Ржать тут можно с джуна, пытающегося на C++ писать сервисы, где без глубокой рефлексии с компиляцией кода при работе сервиса не обойтись, не уходя в глубокие тормоза или не перекомпилируя вообще весь проект при любой изменении схемы в регистре )))
Ответить | Правка | Наверх | Cообщить модератору

297. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (-), 19-Янв-24, 04:15 
> Ржать тут можно с джуна, пытающегося на C++ писать сервисы, где без
> глубокой рефлексии с компиляцией кода при работе сервиса не обойтись, не
> уходя в глубокие тормоза или не перекомпилируя вообще весь проект при
> любой изменении схемы в регистре )))

Ваш экспериенс с дотнетом все же врядли релевантен - это здоровенный интрузивные рантайм, который к тому же крайне редко используется в пингвине. Поэтому экстраполировать такой опыт на совсем другой кейс - и еще наезжать кто тут джун - выглядит довольно специфично со стороны, я б сказал. И уж как минимум я точно не буду доверять таким данным всерьез. Ибо 50/50 что окажется на самом деле какими-нибудь виндодотнетопроблемами и - вот - самоуверенным НеДжуном экстраполировавших их на весь мир.

Ответить | Правка | Наверх | Cообщить модератору

310. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 19-Янв-24, 20:10 
В том то и прикол, что Вы откровенно занимаетесь демагогией, даже не попытавшись ответить на вопрос, как писать gRPC сервисы на C++, если сервисов сотни, схемы все реестре и используются еще и для сотен топиков Confluent. На практике, тут выбор заканчивается между JVM и CIL. И то и другое замечательно живет в Linux под k8s. Но темпы развития Java за последние годы существенно уступают темпам развития C#, что и склоняет в его сторону.
Если Вы даже попробуете перекомпилировать сотни сервисов на C++ при каждом изменении версии схемы protobuf в реестре, то убедитесь, что тот ворох кода, который генерирует protoc, включая связанные с ним классы, очень незначительно уступает по объемам аналогичным сборкам для JVM или CIL.
Судя по Вашему догматизму, Вам исключительно недостаток опыта не позволяет признать, что есть области применения, где рефлексия может дать намного больший прирост производительности, чем отказ от JIT и GC.
Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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