The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


133. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/–
Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 17:32 
чем "умнее" процессора, тем тупее компиляторы вашего любимого языка!

пс: Нафиг надо, скажем прямо. (ц)

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

151. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/–
Сообщение от User (??), 14-Янв-24, 19:36 
Я так понимаю, ускорение достигнуто пепеписыванием на ассемблер,да? Ведь да?
Ответить | Правка | Наверх | Cообщить модератору

157. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/–
Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 21:43 
вы слишком высокого мнения о секте "могучего языка", пока научились только сравнивать (даже не читать) выхлоп собственного "могучего" компилятора.
Ответить | Правка | Наверх | Cообщить модератору

167. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +2 +/–
Сообщение от Аноним (-), 14-Янв-24, 22:52 
> вы слишком высокого мнения о секте "могучего языка", пока научились только сравнивать
> (даже не читать) выхлоп собственного "могучего" компилятора.

Как грится вы нашли друг друга. Два зайца-маздайца. Можете, вот, патчами на ассемблере перекидываться, между собой и даже майкрософту их слать.

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

172. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/–
Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 23:18 
> Как грится

праграммиравайдавай, тебе же "кушать" надо.

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

174. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/–
Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 23:43 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

что за "нечитабельность"?

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

178. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/–
Сообщение от Аноним (-), 15-Янв-24, 00:09 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> /net/inet_sock.h?id=3e7aeb78ab01c2c2f0e1f784e5ddec88fcd3d106
> что за "нечитабельность"?

Скажите спасибо комитету придурков и хреновой спецификации struct, ну и в результате компилеры делающие скажем прямо 1 довольно большой unspecified на эту тему.

Простой вопрос: сколько байтов ЭТО в памяти жрет? А, "зависит от alignment" - при том что даже стандартного способа это указать его нет и компилер сделает "что-то"? Ну вот и оказывается что упаковать 2 числа в 1 u32 может быть куда эффективнее по генерируемому коду и скорости операций.

А вы можете это на асме хреначить. Вон там колибри ос как раз очень ждет помощников в переписке с 32 на 64, заодно узнаете почему остальные асм не хотят юзать без реально мощных причин.

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

182. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/–
Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 00:28 
> Скажите спасибо комитету придурков и хреновой спецификации struct, ну и в результате
> компилеры делающие скажем прямо 1 довольно большой unspecified на эту тему.

:) я в таком комитете не состою

> Простой вопрос: сколько байтов ЭТО в памяти жрет?

там же нет необходимости в выравнивании, "степень двойки" ведь говорили они. :\

> А, "зависит от alignment"
> - при том что даже стандартного способа это указать его нет
> и компилер сделает "что-то"?

во как О_о, ругаем язык или компилер?

> Ну вот и оказывается что упаковать 2
> числа в 1 u32 может быть куда эффективнее по генерируемому коду
> и скорости операций.

На всех ли архитектурах?

> А вы можете это на асме хреначить.

а вот этого не надо, то есть указывать мне что-либо делать или не делать, ибо я вам не указывал, что делать, я всего лишь спрашиваю - зачем вы это делаете именно таким способом, а не иначе. А мне вовсе ничего делать не надо :)


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

239. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/–
Сообщение от Аноним (-), 16-Янв-24, 02:14 
> :) я в таком комитете не состою

Я бы удивился если опеннетчика в ISO занесло. Это про ISO было если что :))

>> Простой вопрос: сколько байтов ЭТО в памяти жрет?
> там же нет необходимости в выравнивании, "степень двойки" ведь говорили они. :\

Я вроде простой вопрос задал. К сожалению комитет придурков так построил стандарт что на этот вопрос нет хорошего ответа. И это грабли. Что еще хуже, контроль над их ручкой тоже квазинестандартными вендорскими расширениями делается. Про ABI vs struct даже и упоминать неудобно.

Поэтому сделать именно красивое, современное, структурированное апи на сях? В принципе это можно. Но, к сожалению, будут определенные нюансы. Правда сейчас на это все же некоторые (включая сабж) забили и все равно так делают, ибо позитивные стороны от нормального апи - зачастую перевешивают. Но вот тут - контрпример вышел.

Или представьте себе насколько красивее был бы код если бы поля пакета "в провод" можно было вписывать как изменение полей struct. Но из-за вооооон того фактора этот фортель если и работает то только местами, с больщими оговорками, а такой код - напрочь непортабельный. И даже так все же иногда делают, даже почтенные фирмы типа ARM какого или STMicro. "Ахренли, с вот этими компилерами работает же!".

Представляете - у ARM совершенно нормально определить "железку" чипа в духе


typedef some_hw_t struct {
volatile uint16_t reg1; 
volatile uint16_t reg2_field1:11; 
volatile uint16_t reg2_field2:5; 
} some_hardware_t

...и обычно это - работает. Хоть ниоткуда не следует что обязано. В этом примере у железки 2 16-бит регистра, при том второй доступен как 2 битовых поля, 11 и 5 битов. Современные компилеры даже так то чекнут что туда адекватное число вписывают.

Если попытаться загнать 50 в .reg2_field2 (скорее ->reg2_field2 ибо инстанс железки заводится как указатель на базовый адрес железки) - который 5-битный - компилер выдаст на это варнинг, ибо максимум который 2^5 может представить это 32. И это так то клево и круто. Но совершенно непортабельно и то что это работает - в общем то случайность. И по части битов, и по части align, там сразу два фэйла в 1 примере.

Т.е. в принципе это есть, это работает, код красивый и даже компилер малость чекает вменяемость того что вписывают в битовые поля. Проблема только в том что работа этого кода - случайность. Шаг в сторону и...

>> и компилер сделает "что-то"?
> во как О_о, ругаем язык или компилер?

Комитет придурков, за то что не удосужились менее отшибленые спеки ЯП сделать. Где например вон то поведение будет чем-то гарантированным а аспекты типа align - подконтрольными. В этом смысле Zig по моему допер вкатить явный атрибут struct что оно packed. А может и хруст.

>> числа в 1 u32 может быть куда эффективнее по генерируемому коду и скорости операций.
> На всех ли архитектурах?

1) Большинство того что поддерживает линух минимум 32 а сейчас скорее 64 бита.
2) Компилер обычно предвычисляет все что можно оформить константой и это будет один load 32 бит константы.
3) Вгруз 32 бит константы как правило не является проблемной операцией для 32 бит и тем более 64 бит платформ.
4) В случае продвинутых оптимизеров типа LTO это порой может быть сделано из чужих частей, если подхоящее уже было где-то. В этом месте компилер может дать мастеркласс любителю асма, вспомнив что кило кода назад в тот регистр подходящую константу уже, давайте-ка реюзнем. А человек потеряется в треке регистров на длинную дистанцию.

И да, одна из траблов с struct кроме голимого их определения и align "от фонаря" - то что компилер может иногда сделать не очень хороший код. Особенно - с битовыми полями. Там где это не важно - красота API может перевесить. Но это не тот случай. И тут может выйти не халявно по коду или памяти в горячем куске. А это хреново.

С другой стороной макросами можно халявное компилтайм формирование этого всего.
Скажем нечто в духе


#define MAKE_U32(hi16,lo16) ((hi16) << 16) | ((lo16) & 0xFFFF)
#define DECODE_LO16(a) ((a) & 0xFFFF)
#define DECODE_HI16(a) (((a) >> 16) & 0xFFFF)
uint32_t a = MAKE_U32(0x1020,0x3040); // Same as a = 0x10203040

Примечание: так не стоит делать без хорошей нужды. Ибо макросы в си это некие грабли. Зато все ЭТО может быть (и почти всегда будет) compile-time предвычислениями. А в реальный код это все пойдет как заранее посчитанные константы, т.е. вон та математика - на фазе компила, а не в рантайм. При том можно сохранить логическое биение на части. Это слабая и более дурная форма того что плюсеры называют constexpr. Вот тут код может быть очень эффективный и - лучше чем с struct, и по части памяти куда предсказуемее, u32 это u32, сильно меньше загонов чем struct vs align.

При желании к вон тому в принципе можно компил тайм верификацию приделать, скажем что hi16/lo16 не менее 0 и не более 65535. И попытки дать макро левак завалят компил. В сабже можно посмотреть как именно такое сделать (да, забавно что макросы могут быть ассертом времени компила "до кучи").

NB: продвинутые глобальные оптимизеры типа LTO иногда создают забавные результаты - казалось бы неудачный код может внезапно оказаться самым эффективным. Может зависеть от порядка кода, это затрагивает глобальные оптимизации типа реюза ранее вгруженых констант для иного блока кода.

> лишь спрашиваю - зачем вы это делаете именно таким способом, а не иначе.

Обычно сишники делают что-то странно выглядящее только если это имело некий технический пойнт. В этом случае пойнт - размещение в памяти (vs выравнивание) и (возможно) менее эффективный код для работы с struct ибо возможны, вот, загоны с выравниванием. А заодно возможно и с clamp математики до 16 битов под u16. Ну а 32 битное число - предмет заметно более простой...

> А мне вовсе ничего делать не надо :)

А, ну понятно, не ошибается тот кто ничего не делает, так то удобно но говорят есть нюанс :)

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

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

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




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

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