Как стать автором
Обновить
122
0
Sergey G. Brester @sebres

Senior Engineer; Data Scientist; Security Auditor

Отправить сообщение

Если речь про что-то типа NUMA Affinity или CPU Pinning и т.п., то будет достаточно добавить --cap-add=sys_nice и/или прописать кастомный seccomp, разрешающий numactl в контейнере.
Если docker только про упаковку, и безопасность не парит совсем (равнозначный хосту контейнер), можно дать ему --privileged и забыть про привилегии совсем.

> А корректный проброс numa? С этим даже у VMware проблемы

Ну, vmware - vmware рознь...
Если это про Tanzu и ко (контейнеризация) - никогда не слышал про те "проблемы"... Можно ссыль?
Если же про VMs, то как раз у контейнеризации тут должно быть всё много лучше и проще чем у "настоящей" виртуализации, собственно по определению обеих... Ибо контейнерная технология напрямую использует физические ресурсы ядра операционной хост-системы, а не эмулирует их как виртуальные компоненты для каждого экземпляра гостевой VM.
Т.е. как изоляция, так и противоположное действие много проще там (capabilities, namespaces, control groups, mapping и вот это вот всё на уровне ядра).
Поэтому собственно контейнеры - это больше про упаковку, чем про "безопасное", полностью изолированное от хост-системы и других гостей, окружение (как оно декларируется у виртуализации).
По этой же причине совершенно нормально пускать контейнеры в гостевой VM, при том что наоборот - это скорее исключение (и имеет смысл только в узко-специфических случаях, типа легаси софта виртуализации и т.п.)

Нет, не приводятся - double он и в Африке double, и что там, что тут - 64 бит (размеры floating-point data types не зависит от разрядности и одинаковы и для x86 и для x64). При этом даже для x86, внутренние FPU регистры - 80 бит. Различие может быть лишь в оптимизации, да в используемых инструкциях (mulsd vs fmul).

Приведённые числа это n в смысле L(n)?

Да.
Гипотеза не работает для большинства значений n в районе 906 150 257 ≤ n ≤ 906 488 079. В этой области суммирующая функция Лиувилля достигает максимального значения 829 при n = 906 316 571.

(кстати 829 а не 849 как написано в статье).

Совершенно верно... Вообще очень странные тесты...
В конкретном случае - var vs let vs const vs sloppy там по большей части вообще измеряется spreading array mutations & push (+ память/кэш всех уровней, + GC, + тому подобное), но никак не заявленное в названии теста.

Если переписать тест хотя бы без вызова push и spread-op (что справедливо ибо объявленная g всё равно immutable), всё очень сильно изменится (и соответственно возможно var будет быстрее только лишь sloppy, проигрывая и let и const):

- g.o = function(x) { g.e.push(...[1,2,3]) }
+ g.o = function(x) { g.e.push }

"Возможно" - потому что оверхед собственно измерения и соответственно шумы и погрешности будут много выше той незначительной разницы (если она вообще есть в SpiderMonkey или V8 при компиляции в браузере).

<img src="боромир-мим.jpg"/> Нельзя просто взять и померить разницу в скорости var vs let vs const в JS в браузере, просто потому что там нет подходящего быстрого инструмента (цикла) для измерений, так чтобы при компиляции var, let или const результат не вырождался тупо в константное выражение, посчитанное на стадии компиляции цикла.

Т.е. даже что-то подобное нижеследующему вряд ли покажет ту разницу реально (и те +13ms или +173ms ниже тупо не являются какими-либо флуктуациями опять же из-за огромного overhead сверху):

// 1e9 итераций, const vs var:
(() => { const x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e9; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 1057}
(() => { var   x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e9; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 1070}

// 1e10 итераций, const vs var:
(() => { const x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e10; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 13077.5}
(() => { var   x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e10; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 13250.1}

В 98-99 гг?
Я где-то в году так 2015-м эту утку снова встречал, причем с кучей комментов поверивших в это людей.
Особенно доставляет, что икра той жабы чёрная и мелкая (т.е. с красной икрой ну никак не возможно спутать) и в 2015-м это всё прекрасно гуглится.

Выглядит как-то так...
Икра откладывается в виде шнуров длиной до 1,5-1,8 м. Икринки в шнуре расположены в 2 ряда. Диаметр яйца 1,1-1,5 мм.
Икра откладывается в виде шнуров длиной до 1,5-1,8 м. Икринки в шнуре расположены в 2 ряда. Диаметр яйца 1,1-1,5 мм.

Два контакта по 65*65 нм нельзя изготовить на литографе для работы с нормами 90 нм.

Ну во первых строго говоря это не совсем так, вернее совсем не так (и я даже не про множественное экспонирование)...
А во вторых изменением архитектуры (например другая компоновка типа тех же интелёвых Foveros, ODI, Co-EMIB и т.п. 2.5D или 3D stacking) можно на 90 нм литографе в теории сделать хоть 10 нм (ну типа в девять "слоёв" если).
Я не говорю сейчас что просто и без проблем, я лишь собственно про "нельзя изготовить".

Конечно же Sissi, кто-же еще...
В традиционном, восточном (китайском?) свадебном платье :)

Зачем дергать при каждом запуске и держать список из 12 тысяч с гаком команд (ака wordlist) для каждой сессии bash, тем более если оно нужно то бывает редко-редко.

Тогда уж лучше как-то так:

# howto () { curl -s cheat.sh/$1; }
complete -C 'filter () { howto :list | grep "^$2"; }; filter' howto

К звуку это отношения не имеет. И замена довольно распространенная в IT (да и не только там)...
Например µs -> us (потому что ms уже занято за миллисекундами).

Ну как близко... https://stackoverflow.com/a/2246793

Проблема с теми AI здесь всегда собственно обучающая выборка - на чем его натаскивают и насколько это "правильно" им разбирается, от "синтаксиса" и "морфологии" до абстракций каких-нибудь... А сарказм если, а пограничные условия какие-либо, и т.п.

Притом что врёт местами безбожно. Например в случае sqlite про скорость оно всё с точностью наоборот. Т.к. sqlite не умеет в оптимизацию NOT IN () чтобы юзать кортёжный индекс (type,id), т. е. получим fullscan со всеми вытекающими.
Более того не просто соврамши - а конкретно так, ибо big-O в случае NOT IN () сильно так нелинейно будет.

Прув на Tcl (просто мерить сподручнее и быстрее)
% sqlite3 db :memory:
% db eval "CREATE TABLE pages ( type TEXT, id TEXT, content TEXT, PRIMARY KEY (type, id) ); CREATE TABLE pages_done ( type TEXT, id TEXT, PRIMARY KEY (type, id) );"
% set i 0; while {$i < 10000} {incr i; set t "type$i"; set c "content $i"; db eval {insert into pages values(:t, :i, :c)}; if {$i & 1} {db eval {insert into pages_done values(:t, :i)}}}
% db eval {select (select count(*) from pages), (select count(*) from pages_done)}
10000 5000
% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NULL LIMIT 4999,1}}
4185.05 µs/# 239 # 238.95 #/sec 1000.226 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) NOT IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
1520435 µs/# 1 # 0.658 #/sec 1520.435 net-ms

Для случая IN () AI был бы прав:

% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NOT NULL LIMIT 4999,1}}
3879.22 µs/# 258 # 257.78 #/sec 1000.839 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
2326.35 µs/# 431 # 429.86 #/sec 1002.658 net-ms

Тоже резануло по глазам...
Это при том что он прямо об обратном говорил (и неоднократно на моей памяти).
Да и как оно возможно вообще, когда такое изменение вызовет целую лавину (с потенциальными конфликтами везде и вся, и т.д.), ибо как писал упомянутый RMS:

"When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible."

Нужно наверно уточнить что здесь значит "in a single program" - link, merge or combine code of two different programs with GPLv2 and GPLv3.

По мобильному — ещё хуже, РФ — 85-е, РБ — 135

Центр Гамбурга (Германия - согласно той статистики 33-е место), 4G/LTE с трудом выдает 3Mbps (и пинг за сотню), при том что в различных крыльях здания, расположенного буквой П, местами тот 4G падает до E а то и вообще до 0 (причем в разных местах у разных провайдеров по разному - в одном месте у одного 0 или E, в другом - у другого).

Отъехав от Гамбурга на какие то 5 км (да и в самом городе местами) вы можете вообще потерять связь. Совсем. Езжу 15км от дома до работы и местами (всегда одни и те же три/четыре точки) - тупо дыра, ни интернет-радио, ни ватсап, ни ТГ - ничего, пока тупо их не проедешь.

покрытие около г. Гамбург для разных сетей

O2 / Telefonica
O2 / Telefonica
D2 / Vodafone
D2 / Vodafone
D1 / Telekom
D1 / Telekom

И это не в одной Германии так. Поездив по миру, я много где наблюдал подобную картину (за несколькими исключениями, например в той же Голландии и Норвегии). При том что в РФ как раз очень редко случалось, что связи нет вовсе. И я не про "внутри МКАДа" сейчас... Даже, как-то лет 10 назад, проехав 2 тысячи км, Санкт-Петербург - Вологда - Киров - Пермь - Екатеринбург, связь по ощущениям была почти везде.
В той же Германии 10 лет назад было совсем печально всё.

гигабит по воздуху доступен

Да-да... и травка зеленее, и солнышко желтее.

В массе своей 50-100 а то и 10Мбит/с для стационарного-то интернета (DSL) - уже считается хорошо. Стекловолокно тянут конечно тут и там, но как-то всё не разгонятся.
По воздуху же гигабит - вообще что-то из области фантастики. И даже если он номинально имеется (по договору 5G присутствует), то по факту выше 4G+ (а реально где-то в районе 250Мбит/с) я скоростей не видел, и не слышал ни от кого пока.

Как мне кажется проблема в той статистике, что если "сложить" человека (сидящего рядом с 5G антенной) с условными 450Мбит/с и 9 человек с 10Мбит/с, то в среднем получим тот полтинник (согласно статистике 53.65Mbps). Только его по факту как не было так и нет.
Ну и парадокс выжившего сверху (из мест с 0Мбит статистика тупо не идет).

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

Для замеров скорости мелкого и быстрого кода, нужно использовать number=1000000 и выше.

Не нужно измерять print, читайте внимательнее, в статье написано как оно измерялось...

>>> from timeit import timeit
>>> for s in ('f"{x} {y}"', '"{} {}".format(x, y)' ,'x+" "+y', '"%s %s" % (x, y)'):
        print(timeit(s, 'x, y = "Hello", "World"', number=1000000), s)
0.1258036000000402 f"{x} {y}"
0.4175639999999703 "{} {}".format(x, y)
0.2175986999999395 x+" "+y
0.3835477999999739 "%s %s" % (x, y)

euch пишется с маленькой буквы...

Liebe Kolleginnen und Kollegen, ich begrüße Euch recht herzlich zu...

ЧЯДНТ Бывают исключения, когда нужно и можно, что бы, значит, уважение показать.

от местных разговорных обычаев зависит.

Про Kann-Darf-Soll? Не зависит это от "местных разговорных обычаев" никак. Что в Гамбурге, что в Мюнхене, что в городе, что в деревне всё одно будет (разве только местами с жутким выговором).

А чего там уметь то?

Мешаем 10K раз текущие год-неделя и/или год-месяц, ну и только год с каким-нибудь секретом и "семечками", всё это в строчку по основанию 36 и получаем кучу доменов видаrmncxhceao.tld. Аппараты будут пробовать стучаться по всем 10K доменам, а ботоводу нужно создать из тех вариантов только 1 для года, 1 для года-месяца, чтобы отдать "команду".
Ну или ещё один для года-неделя, если сильно срочно надо или там увезти или "поднагрузить" чуть-чуть уже проданную бот-сеть нужно.

Есть и много хитрее алгоритмы, но мы тут не будем скрипт-киддис обучать.

Вопрос только в том, известна ли конкретная реализация DGA (расковыряли ли то всё уже или ещё нет), чтобы проверить какой-либо трафик. Заблокировать же это всё, да ещё и на месяц/другой вперед - много сложнее (и дороже). Можно конечно просто прикинуться "аппаратом" и искать те домены каждый день и абузить сразу по созданию, однако пока найдем, пока залочим...

Нет! От слова совсем. Не вводите людей в заблуждение, пожалуйста.

Начнем с того что вы путаете Euch (личн., 2-е л., мн.ч., дат.п., типа "Вам, друзья") и Ihnen (личн., вежл., дат.п., типа "Вам, молодой человек").
Т. е. Euch вы можете использовать когда вы спрашиваете несколько человек, или если мы в десятом веке.

Конкретно фразы "Kann ich Ihnen helfen?", "Darf ich Ihnen helfen?" и даже "Soll ich Ihnen helfen?" являются практически синонимами (хоть и с оттенками "могу ли я", "смею ли я", "нужно ли" соответственно), но и в случае с инвалидом Soll тут не несёт никакого оскорбительного оттенка, пока это либо специально интонацией не выделить. Либо "магическим" словом каким, типа etwaили noch :

Soll ich Ihnen etwa helfen?! -> Мне что-ли вам еще и помогать нужно?!

Ну и коренной немец в случае вежливой просьбы помочь использует скорее что-нибудь типа:

Kann ich Ihnen behilflich sein? -> Могу ли я вам помочь (быть полезным)?

И да, вот тут уже можно использовать только Darf вместо Kann, а Soll просто по смыслу не подойдет (опять же без всякого оскорбительного оттенка), просто это будет означать:

Soll ich Ihnen behilflich sein? -> Должен ли я вам быть полезным.
(что, согласитесь, звучит никак)

С остальным же тоже передергивание...

Т. к. ни "Brauchen Sie Hilfe?" ни остальные тоже не несут никакого оскорбления или издевки в случае вопроса к инвалиду или вообще к человеку нуждающемуся в помощи.
Кроме разве что "Wie kann ich Ihnen helfen?", который просто не очень подходит, ибо как правило используется как вопрос, по телефону или в прихожей например, к незнакомому человеку ("Вам чем-нибудь помочь?" или "Чем я вам могу помочь?"), короче не совсем отсюда.

И да. Немецкий Sollen и английский Shall похожи по смыслу, но в очень определенных формах (например в том же повелительном наклонении, в Präteritum или как раз в архаичных конструкциях).

Попробовал на 3.11 (в сравненини с 3.10) код из "Sexy primes, «медленный питон» ...". Как чистая "числодробилка" оно всё ещё не очень комильфо...

где-то даже чуть медленнее ...
-$ python3.10 sexy-primes-test.py 30K org 5
+$ python3.11 sexy-primes-test.py 30K org 5

-  org ===  4.07481 s ===    4074.81 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+  org ===  5.29273 s ===    5292.73 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

- mod1 ===  3.96475 s ===    3964.75 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ mod1 ===  4.87965 s ===    4879.65 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

- mod2 ===  2.22087 s ===    2220.87 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ mod2 ===  2.48653 s ===    2486.53 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

- org2 ===  1.70525 s ===    1705.25 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ org2 ===  2.34608 s ===    2346.08 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-  max ===  0.02840 s ===      28.40 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+  max ===  0.03147 s ===      31.47 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

- orgm ===  0.03075 s ===      30.75 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ orgm ===  0.04177 s ===      41.77 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-gesiv ===  0.01476 s ===      14.76 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+gesiv ===  0.01606 s ===      16.06 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-gesim ===  0.00567 s ===       5.67 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+gesim ===  0.00565 s ===       5.65 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-siev1 ===  0.00160 s ===       1.60 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+siev1 ===  0.00194 s ===       1.94 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-siev2 ===  0.00156 s ===       1.56 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+siev2 ===  0.00201 s ===       2.01 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-osie1 ===  0.00229 s ===       2.29 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+osie1 ===  0.00283 s ===       2.83 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

-osie2 ===  0.00212 s ===       2.12 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+osie2 ===  0.00237 s ===       2.37 mils  |  951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]

где-то действительно чуть быстрее ...
-$ python3.10 sexy-primes-test.py 1M max 5
+$ python3.11 sexy-primes-test.py 1M max 5

-  max ===  4.84150 s ===    4841.50 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+  max ===  4.00079 s ===    4000.79 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

- orgm ===  3.93674 s ===    3936.74 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+ orgm ===  3.53014 s ===    3530.14 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-gesiv ===  0.59956 s ===     599.56 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+gesiv ===  0.61838 s ===     618.38 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-gesim ===  0.22313 s ===     223.13 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+gesim ===  0.21676 s ===     216.76 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-siev1 ===  0.06775 s ===      67.75 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+siev1 ===  0.06535 s ===      65.35 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-siev2 ===  0.06941 s ===      69.41 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+siev2 ===  0.06778 s ===      67.78 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-osie1 ===  0.10289 s ===     102.89 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+osie1 ===  0.10788 s ===     107.88 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

-osie2 ===  0.08179 s ===      81.79 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+osie2 ===  0.08253 s ===      82.53 mils  |  16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]

Тесты делал на i7-4790 @ 3.60GHz, обе версии собирались локально с оптимизацией (configure --enable-optimizations, -mtune=native, -O3 и т.д.).

Хотя судя по всему что-то в этом PEP 659 "кэшировании" (ака specializing adaptive interpreter) всё-таки есть, надо будет потискать в бою.

1
23 ...

Информация

В рейтинге
4 688-й
Откуда
Hamburg, Hamburg, Германия
Дата рождения
Зарегистрирован
Активность