Но через BPF можно сделать доступ к контексту приложения, по крайней мере. Т.е. разбивку по экспериментам - я так понял, это очень важно для автора и его команды.
Если уж через perf собирать, то имеет смысл чаще, кмк. Возможно, получится выбрать sampling rate пониже, чтобы самортизировать нагрузку, да. Но в целом мысль такая, что режим открутки dwarf в perf очень расточителен с точки зрения количества памяти, к которой он прикасается и копирует. Было бы здорово, если бы perf умел прямо в обработчике прерывания откручивать через dwarf, но Линус уже сказал как-то в своей манере, что dwarf раскрутки в ядре не будет - слишком сложный код (turing-complete, вроде как). Ждем, когда Intel CET shadow stack станет более доступной и поддерживаемой.
Можно попробовать -fnoomit-frame-pointer -momit-leaf-frame-pointer. Может помочь компилятору таки использовать %rbp в самых горячих листовых функциях. И раскрутка в большинстве случаев работать будет - когда %rbp не используется.
Я бы тут был осторожным. Допустим, сэмплируем 64 ядра, 100 раз в секунду. Если сохранять 256 КБ стековой памяти, то это 64*100*256*1024/2**30 = ~1.5 ГБ/сек. Нетривиальное количество памяти для копирования - несколько процентов общей memory bandwidth, и last level cache выметет...
У такого дифференциального flame graph есть неудобство - поскольку форма строится по первому флеймграфу, то если функция / путь вызова есть только во втором, ее не увидишь. Приходится менять местами первый и второй, чтобы убедиться, что ничего не пропустил. Есть еще рабочий вариант использовать в качестве ширины среднее между профилями, то тоже не идеально.
По поводу проблемы, что если одна и та же функция есть во флеймграфе много раз, то ее сложно увидеть - посмотрите на pprof, и в частности на фичу из этого пулл реквеста. С ней жить должно стать повеселее.
T-Mobile либерально относится к неродственникам на семейном плане. На пятерых связь обходится долларов в 25 на человека. И да, ни разу не видел этого межсетевого роуминга.
Надо же, оказывается у этого есть научное название. Я в студенческие времена такое сам изобрел — правда, немного в другом виде. Если, уже лежа в кровати, вспоминал, что надо с утра что-то взять, то (поскольку вставать было лень) брал стоящий рядом будильник и ставил его под кровать. С утра сразу вспоминалось :) Правда, есть важный момент — как только якорь сработал, надо действие СРАЗУ выполнить. Иначе забывается мгновенно.
Классическое использование термина «регулярное выражение» означает «выражение, описывающее некоторый регулярный язык». Это, как мы видим, не всегда так, но мою чуткую душу это коробит, так что вот и напоминаю.
Рекурсивное регулярное выражение — это уже не регулярное выражение, а стековая машина. Это не делает их менее полезными, но важно понимать, что это уже не конечный автомат.
Предложение Путина поддерживаю полностью. Медведевское летнее время увеличило разницу московского времени с калифорнийским до 12 часов зимой. Работать невозможно. Как можно говорить о каких-то инновациях и инвестициях, если сами отгораживаемся часовыми поясами от западного мира. Я бы вообще подумал на тему сделать время западной части России ближе к Западному, а восточной — ближе к Восточной. Чтобы в одном конце было удобнее работать с Западом, а в другой — с азиатами.
Я бы ожидал, что используется shift-and-add1, тот, что Вы указали первым. Интересное наблюдение: если при реализации такого алгоритма умножения доступна O(1) проверка «является ли текущий обрабатываемый бит самым крайним слева/справа», то сдвиги-сложения можно остановить в нужный момент, и алгоритм в некотором смысле становится O(ln N).
Еще интересная тема — деление. Вот оно уж точно в той или иной степени итеративное, и количество итераций зависит от входных данных. Другое дело, что современное железо старается эти итерации всячески амортизировать и дать гарантированную оценку сверху сложности операции деления для любых входных данных.
Это неважно как раз. Даже если умножение машинных слов реализовать руками, с точки зрения алгоритма это все равно будет константа. Весь сыр-бор начинается именно если размер промежуточного и конечного результата не фиксирован, а пропорционален N.
Это верное замечание. Действительно, факт того, что числа длинные меняет сложность алгоритма. Константы могуть быть разными, но сложность действительно будет линейной, если только в задаче не достаточно нахождения модуля.
Но через BPF можно сделать доступ к контексту приложения, по крайней мере. Т.е. разбивку по экспериментам - я так понял, это очень важно для автора и его команды.
Если уж через perf собирать, то имеет смысл чаще, кмк. Возможно, получится выбрать sampling rate пониже, чтобы самортизировать нагрузку, да. Но в целом мысль такая, что режим открутки dwarf в perf очень расточителен с точки зрения количества памяти, к которой он прикасается и копирует. Было бы здорово, если бы perf умел прямо в обработчике прерывания откручивать через dwarf, но Линус уже сказал как-то в своей манере, что dwarf раскрутки в ядре не будет - слишком сложный код (turing-complete, вроде как). Ждем, когда Intel CET shadow stack станет более доступной и поддерживаемой.
Можно попробовать -fnoomit-frame-pointer -momit-leaf-frame-pointer. Может помочь компилятору таки использовать %rbp в самых горячих листовых функциях. И раскрутка в большинстве случаев работать будет - когда %rbp не используется.
Я бы тут был осторожным. Допустим, сэмплируем 64 ядра, 100 раз в секунду. Если сохранять 256 КБ стековой памяти, то это 64*100*256*1024/2**30 = ~1.5 ГБ/сек. Нетривиальное количество памяти для копирования - несколько процентов общей memory bandwidth, и last level cache выметет...
У такого дифференциального flame graph есть неудобство - поскольку форма строится по первому флеймграфу, то если функция / путь вызова есть только во втором, ее не увидишь. Приходится менять местами первый и второй, чтобы убедиться, что ничего не пропустил. Есть еще рабочий вариант использовать в качестве ширины среднее между профилями, то тоже не идеально.
По поводу проблемы, что если одна и та же функция есть во флеймграфе много раз, то ее сложно увидеть - посмотрите на pprof, и в частности на фичу из этого пулл реквеста. С ней жить должно стать повеселее.
bpf как и perf откручивает стеки через frame pointers. Так что, по крайней мере в этой части достоинств не будет.
Еще один недостаток такого профайлера, это что стеков ядра увидеть не получится - я так понимаю, GDB обязательно дождется выхода из системного вызова.
Скажите, MSG_ZEROCOPY используете?
www.orcaware.com/svn/wiki/Svnmerge.py
Еще интересная тема — деление. Вот оно уж точно в той или иной степени итеративное, и количество итераций зависит от входных данных. Другое дело, что современное железо старается эти итерации всячески амортизировать и дать гарантированную оценку сверху сложности операции деления для любых входных данных.