Comments 31
Не забываем: операция записи возвращает, сколько
она может записать по адресу назначения,
Здесь, к сожалению, описка: операции записи write возвращает количество уже записанных байт. И тогда всё дальше по тексту.
выдавала вывод в канал со скоростью ~35 гибибайт/с^3.
Долго думал, что же за кубические секунды такие. А статья отличная!
На "КибиБ“ тоже глаз спотыкается. По-моему либо КиБ либо КибиБайт.
А статья да, очень хороша, за статью автору спасибо.
Точнее, либо КиБ, либо кибибайт (с маленькой буквы): https://ru.wikipedia.org/wiki/Двоичные_приставки
(Удалено: у Хабра маркдаун не той системы.)
getuserpagesfastделает именно то, что делал бы CPU, но на программном уровне
По стеку видно, что вся работа со страницами памяти выполняется програмно, но судя по статье, это должно выполняться на CPU. В чем подвох?
Почему "pipe" перевели как "канал", если "channel" не совсем "труба".
В чем смысл юзания сдвигов size_t buf_size = 1 << 18; // 256 КибиБ ?
256 * 1024 более наглядно. С первой строки дать понять, что тут низкоуровневый код, а не эти ваши js?:)
Видимо, это пример проявления гипотезы Сепира — Уорфа, которая утверждает, что, грубо говоря, язык влияет на мышление. Мне, как и автору, в данном контексте удобней мыслить на языке сдвигов (точнее, на языке степеней двойки).
Старые и слабые процессоры любой двоичный сдвиг могли выполнить за один такт, а умножение делалось за множество тактов.
Рискну утверждать, что все компиляторы созданные за последние 30 лет поменяют умножение на сдвиг. Кроме того, это вообще константа, которая вычислится в процессе компиляции и загрузится, как константа. Таким образом использования сдвига вместо умножения не оправдывается никакими техническими проблемами. Я лично согласен с автором верхнего комментария, что писать 256 * 1024 намного лучше.
И в Вас, как и в авторе комментария выше, это выдает человека, который системным программироварием в серьез не занимался. По той причине, что "там" привычнее видеть сдвиги, а умножения вызывают острое желание развидеть код. Но главное в этом - точно знать какой код будет на выходе, без необходимости лезть с дизасемблером и смотреть что там нагородил компилятор. Вплоть до того, что сборка с условным О-ноль это правило.
size_t KiB = 1 << 10
size_t MiB = KiB << 10
size_t buf_size = 256 * KiBну и по хорошему эти префиксы должны быть в стандартной либе, чтобы наверняка
И в Вас, как и в авторе комментария выше, это выдает человека, который системным программироварием в серьез не занимался
О-о-о! Моя любимая рубрика: "определение профессиональных качеств и опыта по комментарию на Хабре". Вам с такими талантами надо в отделе кадров работать.
По той причине, что "там" привычнее видеть сдвиги, а умножения вызывают острое желание развидеть код
Ещё раз, речь про определение константы. То что явно более наглядное 256*1024 вызывает странные желания, это проблема скорее смотрящего, а не пишущего
Но главное в этом - точно знать какой код будет на выходе, без
необходимости лезть с дизасемблером и смотреть что там нагородил
компилятор
Чтобы такого добиться надо на ассемблере писать
Вплоть до того, что сборка с условным О-ноль это правило.
Странно, что такой специалист не в курсе, что обычно используют -Os
О-о-о! Моя любимая рубрика: "определение профессиональных качеств и опыта по комментарию на Хабре". Вам с такими талантами надо в отделе кадров работать.
Вы же не будете отрицать, что например человек который может выиграть гонку на автомобилях должен уметь управлять автомобилем?
Ещё раз, речь про определение константы. То что явно более наглядное 256*1024 вызывает странные желания, это проблема скорее смотрящего, а не пишущего
Дружище. Я еще раз подчеркну. Для людей которые занимаются системным программированием, намного удобнее мыслить степенями двойки, которая определяется сдвигами. Это следствие тех задач которые им приходится постоянно решать именно в силу особенностей того как и для чего они программируют.
Чтобы такого добиться надо на ассемблере писать
И именно это, все кто занимается системным программированием, умеют делать. По той причине, что если Вы этого делать не умеете, то Вы не можете заниматься системным программированием. Суть которого - точно знать как работает та система под которую вы пишете свою программу. Языки же типа Си используют чтобы сэкономить себе время.
Я лично никогда Си не использовал. Видимо по причине того, что мне не нужно было писать никогда ядро ОС.
Странно, что такой специалист не в курсе, что обычно используют -Os
Вы будете удивлены сколько еще очень нужных для них вещей не знают специалисты такого уровня. Именно этими причинами и продиктован мой с Вами диалог.
Поймите. Современные коммерчески успешные процессоры работают используя простую идею 0 и 1. То есть той самой степени двойки. И программируя под эти системы, в случае разрешения задач, где фактор максимальной эффективности, ставится во главу угла, вы неизбежно начнете счатать все сдвигами. Не говоря уже о том, чтобы проивзодить конвертацию 16ричной системы в двоичную проводить в уме - не потому что Вы бох конвертации, а потому, что Вы постоянно это используете и знаете насколько это просто. Ну как люди очень легко умножают и делят на числа кратные 10, потому что там нужно добавлять или убирать нолики.
Системным программированием и я в серьез не занимался, но вот всякие задачи, где задержки пониже напрямую конвертируются в прибыль повыше, я решал. И умножение там вполне нормально выглядит.
Нет. Не выглядит. Это еще раз подчеркивает тот факт, что Вы, Ваш мозг, никогда не мыслил категориями которыми мыслил мозг человека который создавал процессор под который вы пишите системную программу.
Я еще раз вызываю к Вам, поймите это не блажь. Это потому, что люди, которые пишут подобные программы не мыслят иначе. Для них нонсенс мыслить чем-то отличным от прямого сдвига.
А сборка с О-ноль в системном программировании за правило потому, что люди считают себя умнее языка и компилятора, а компилятор потом почему-то ломает гениальный код.
А кто написал эти компиляторы?
Вы все время путаете где яйцо а где курица.
избавляет нас от выделения физической страницы, но может столкнуть нас на медленный путь get_user_pages_fast, так как эта функция будет вызываться раз за разом, если страница ни разу не откажет по какой-то другой причине.
Следовательно, если мы не делали memset ранее и, следовательно, не отбраковывали страницы в таблице «вручную
А что в оригинале? Перевод тут явно коряв, и все эти "ибиб/сек" глаз режут.
В остальном статья хорошая, хотя в 19-й сноске (18-й?) всё действительно, запутанно как-то.
Интересно было бы как в в сравнении с tcp на loopback
Правда, причина таких улучшений не вполне очевидна.
Я думаю тут эксплуатируется "знание" того, что физ-память идёт подряд.
Например (не залазия в код ядра) просто 2M страница ремапится на 512 4К страниц через remap_pfn_range.
- buf_ix = (buf_ix + 1) % 2;
+ buf_ix ^= 1;
Так все же, насколько быстры каналы в Linux?