Представлен первый выпуск новой основной ветки nginx 1.23.0, в рамках которой будет продолжено развитие новых возможностей. В параллельно поддерживаемой стабильной ветке 1.22.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В следующем году на базе основной ветки 1.23.x будет сформирована стабильная ветка 1.24...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57385
> Переделан внутренний API, строки заголовков теперь передаются в форме связанного списка.Кто пограмотнее, объясните, какая с этого выгода.
Я искал время от времени случаи, где связный список лучше, чем указатели на массив/двустороннюю очередь, и не мог найти ничего полезней чем "ну когда нужно вставлять один контейнер в середину другого", и даже там на коротких массивах выгоды как правило не было.
Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсь.
Быстрая вставка, быстрое удаление элемента - единственное, что могу придумать.Больше ничего в голову не приходит. Ещё есть конечно вариант, когда суммарный размер всех указателей сопоставим с размером L1D хотя бы, а останавливаться при проходе надо максимум посерёдке - но это явно не тот случай.
https://github.com/matklad/vec-vs-list
Что за ...ня, написанная на ...не, простите?
А самое главное - какое эта ^_^ня имеет отношение к nginx?
Я даже тебе объясню, почему вообще мимо тазика: реализация этих примитивов на езычге, где работа с указателями реализована через libastral (или libanal), может быть совершенно неоптимальной.
С другой стороны бинарный поиск в отсортированном списке - так себе затея, т.е. это tradeoff.
Вот в жизни не поверю, что у них число вставок-удалений превышает число поисков.
> С другой стороны бинарный поиск в отсортированном списке - так себе затея,
> т.е. это tradeoff.
> Вот в жизни не поверю, что у них число вставок-удалений превышает число
> поисков.Да даже если и превышает, ну будет массив указателей на строки размером на 10-30 строк, там вставка не будет сильно медленней, чем в списках. Из-за высокой локальности оно может ещё и быстрее оказаться.
Вставка в связанный список - это 2 указателя заменить, если по-минимуму. O(1)
Вставка в массив указателей - это, простите, сдвинуть N указателей. O(N)
(кроме вырожденного случая вставки в конец массива)
Наоборот, вырожденный случай вставлять в середину массива (это ж надо иметь отсортированный массив), а так всегда добавляется в конец.
Вставка в конец массива (или, если быть совсем точным - всегда в одинаково отдалённую от конца массива позицию) - это O(1), не зависит от числа элементов в массиве, поэтому и вырожденный случай.
возможно, меньшая фрагментация памяти - возможность pre-alloc/pool блоков одинакового размера. при высокой нагрузке это может быть важно.
> возможно, меньшая фрагментация памяти - возможность pre-alloc/pool блоков одинакового
> размера. при высокой нагрузке это может быть важно.Почитал про Pool Allocator, спасибо за место, где в связном списке больше смысла, чем в простом массиве. Но не могу понять по коду nginx, чанки ли там или просто список сам по себе.
Блоки одинакового размера для содержимого хедеров?
Не, конечно это nginx, там всякое может быть. Но не верю.
Выгода от связного списка есть, только если он intrusive, как в ядре линуховом. В остальных случаях классическая реализация с указателем на следующую ноду что асимптотически так себе, что с точки зрения фрагментации кучи. Не зря же в той же жабе в 90% процентов случаев пользуются реализацией на основе массива.
> Выгода от связного списка есть, только если он intrusive, как в ядре линуховом.А какая? Есть какая информация в духе "вот тут мы заменили X на linked list -- и стало слегка/гораздо быстрее", может в LKLM где-нибудь?
Аргументация о том что так называемые "программисты на java", не знающие чем фон неймановская архитектура отличается от гарвардской, используют массивы, а не связные списки скорее говорит в пользу связных списков.
То что "макака-формошлёп" будет использовать неподходящие структуры данных понятно любому настоящему программисту на ANSI C, обильно комментирующему новости на opennet
Ну и как поможет "программисту на java" знания о том, перемешиваются данные и код или нет, в выборе структуры данных ?
Вопрос был о том, почему перешли с массива на связный список.
> Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсьНа самом деле возможность обходить нормальные заготовки как связный список там есть давно. Просто в некоторых специфичных случаях использовались ещё и массивы (например для multi headers - когда в сообщении может быть несколько заголовков с одинаковым именем, как в случае с Set-Cookie). Из-за этого итерация по заголовкам и их значениям превращалась в квест на костылях. Теперь структуры данных привели к одному виду.
>> Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсь
> Теперь структуры данных привели к одному виду.Но зачем было в принципе список использовать? Почему не перейти к массивам? Почему в принципе был выбран именно список? А то вдруг он выбран давным-давно и теперь все хотели бы заменить, но обратная совместимость и не чини что работает.
Читаю ветку и душа радуется. Наконец-то что-то вменяемое, без "ненужно", раста и несоответствий в версиях питона (недавно, как раз, попал в Jinja2 версии 3.1).
Вполне себе профессиональная беседа.
Пришёл на ум ещё один вариант, когда связный список эффективнее - это когда его надо часто на запись блокировать между потоками (вставка-удаление). В случае массива указателей придётся блокировать таковой целиком (или извращаться с частичной блокировкой). В случае связного списка блокировать придётся только непосредственно участвующие записи (одну или две, в зависимости односвязный или двусвязный это список).Но это опять не про nginx.
Ну и на вставку в связный список аналогично хорошо RCU ложится, если возможность в соседнем потоке пролистать список в stale state без нового элемента не напрягает. На удаление - на любителя, прочитать удалённую запись обычно не есть гуд.
Зачем ссылка на изменения на английском и зачем было их переводить по своему? есть же русская версия http://nginx.org/ru/CHANGES.ru
Когда квик в стабильную версию добавят?
>Когда квик в стабильную версию добавят?Гуглу или Фэйсбуку с их миллионами TCP коннектами понятно зачем квик.
А тебе оно зачем?
Ну я замечал, что в 2 раза быстрее сайты загружаются. Так 2 секунды где-то до появления контента, а с этим около 0.5с. В консоли смотрел-сравнивал разницу, там пишет время загрузки ресурсов.
У тебя цифры не сходятся, перепроверь свои навыки в арифметике.
"быстрее сайты загружаются" и "где-то до появления контента" не одно и тоже, может в "2 раза" это до события "load".
> Ну я замечал, что в 2 раза быстрее сайты загружаются. Так 2 секунды где-то до появления контента, а с этим около 0.5с.Это баг в Vue, должны починить. Загрузка сайтов не должна занимать менее двух секунд.
Quic нужен, чтобы под него маскировать любой другой UDP трафик.
откуда дровишки?
Для начала от проекта v2ray и ему подобных. Которые уже кое-что подобное сделали, только на старой версии квика.Но для того, чтобы не светиться как новогодняя ёлка, нужно чтобы квик стал популярным.
Ну а потом придёт masque wg, и маскировка будет встроена в сам протокол.
Хайп "передовых технологий" поймал?
Не раньше, чем поддержку оного в openssl добавят.
Без Сысоева уже не то...
Тем, кто ещё на этом сидит, ещё не начал phaseout, и не готов платить за поддержку - я бы уже советовал задуматься.
> Тем, кто ещё на этом сидит, ещё не начал phaseout, и не
> готов платить за поддержку - я бы уже советовал задуматься.По факту проект закончен. Так бы выпилить из него ненужное типа njs (есть nginx-lua кому надо).
Если из нгинха выпилить ненужное - не останется ничего.
>Без Сысоева уже не то...Без твоего ценного мнения, всё - уже то.
Зачастили как-то релизы nginx-а...