res2001

Добавлю к вышесказанному.

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

Так что маршрут в 20 хопов имеет более высокий шанс показать большее время пинга по сравнению с маршрутом в 10 хопов, даже если он физически и короче.

Для подобных целей уже давно заведены intptr_t и uintptr_t [?], а еще ptrdiff_t [?].
Именно эти типы и стоит использовать для прямой работы с адресами.

Теги C и C++ смешивать не совсем уместно. Это мешает выбору более подходящего варианта ответа.
В C++, например, если нужно только хранить адрес и позволять с ним только определенные операции, лучше мог бы подойти enum class MemoryAddress : uintptr_t;. Пустое перечисление с достаточной шириной и выравниванием избавит от возможности случайно что-то куда-то прибавить или умножить, да и от неявных преобразований убережет. А перегрузка операторов поможет разрешить только определенные операции.
Но в C так не получится.

Спасибо всем неравнодушным и ответившим по существу проблемы.

Всякое решение плодит новые проблемы.(один из законов Мэрфологии)

Похоже время ответить на вопрос и закрыть тему

Context switch per second (Linux) 1.3млн это много или мало?
Если коротко — это для конфигурации
E5-2699v4 — 2шт
RAM 378Gb
Довольно много, но не предел.
Достигнутый максимум 1.5 млн.
Достигнут был при следующих условиях:
Совет от edo1h,

1. mitigations=off, это снизит стоимость переключения контекста;
2. «Зажал» бы частоту процессора и отключил всякие c3, энергосберегающие опции плохо совместимы с короткими запросами.
processor.max_cstate=1 intel_idle.max_cstate=1 к параметрам ядра, плюс поставить pstate-frequency и запустить pstate-frequency -p max (если помогло, то в systemd включаем pstate-frequency@max)

Дал направление копания, итоговый набор параметров ядра совпал с советом выше.
mitigations=off intel_idle.max_cstate=1 processor.max_cstate=1

Замечания jcmvbkbc, res2001, Everything_is_bad натолкнули на мысль разделить задачи сервера на более-менее автономные блоки и исследовать как по отдельности, так и взаимосвязи между ними.

Результат оказался для меня неожиданным (об этом в п.3)

1. Сеть
Тюнинг сетевой подсистемы дал снижение количества прерываний/сек (не слишком значительное, но это положительным образом сказалось на результатах).
Убрал bonding интерфейсов (выигрыш на уровне погрешностей измерения, но иногда(хоть и крайне редко) при работающем bonding наблюдались всплески interrupts, которые полностью отсутствовали при выключенном bonding в течении 4-х дней)
Максимальный размер буферов на адаптере.
Воспользовался tuned + корректировка параметров sysctl.
Профиль network-latency субъективно подошел лучше всего.

2. Работа nginx-а
Тут дало положительный эффект запуск 2-х независимых серверов на 2-х dummy интерфейсах. Не могу пока предположить с чем связано.

3. Неожиданный эффект — т.к. логирование таки необходимо, довольно много сливалось в rsyslog по unix.socket (сеть не вариант, нагрузка выше заметно)
Вот отказ от заливки логов nginx-а в rsyslog снял 75-76% (С 1.3млн до 0.3млн на пиках нагрузки) количества «Context switch per second».
Буквально «на коленке» на python написал заменитель, вся задача — сообщение из unix.socket записать в файл в нужном формате.

Итог, сервер выполняет те же функций:
«Context switch per second» -- снизился на 50% от исходного.
Нагрузка на CPU — снижение примерно на 25-30%.
При тех нагрузках, при которых ранее появлялись отказы, отказов нет.

Понять, что C и C++ - это два разных языка, и либо использовать C++, либо не использовать iostream.

почему такая ошибка со своим mutex

потому что pthread_t шире чем int owner, и как следствие этот тест не работает.

Все до безобразия просто:
Вы выделяете память в момент, когда она вам нужна, а удаляете когда эта память вам более не нужна.
Соотвественно, вам нужна функция array_deinit(), которая возьмет на себя непосильную ношу освобождения памяти в момент, когда вы больше не планируете обращаться к своему двумерному массиву.

В простейшем случае, в С++ подобный функционал оборачивают в класс, который, в свою очередь, обязательно должен почистить за собой память хотя бы в деструкторе.

Также в современном С++ не принято использовать new/delete без веской причины (например, вы пишете супер быстрый, современный контейнер, в котором хотите управлять всеми аллокациями самостоятельно), а рекомендуется использовать умные указатели для работы с памятью.

#define BIT_SET(port, bit) (port |= (1 << bit))

int main(void)
{
    BIT_SET(PORTB, PORTB0);
}

вот такой вариант, с макро-функцией, работает, так как это просто текстовая замена

Он работает, потому что с таким определением BIT_SET PORTB не может быть определён просто как 0x04. Потому что просто текстовая замена 0x04 |= 1 << 0 не имеет смысла. Он определён как volatile ссылка на память с адресом 0x04. Когда ты научишься передавать ссылку на такую память в функцию, функция тоже начнёт работать.

Скорее всего тут дело в кеше процессора. После первых запусков так получилось, что данные оказались в кеше.

Вообще, писать бенчмарки - очень сложно. Надо сначала прогонять тест несколько раз и отбрасывать результаты, а уже потом мерять. Надо быть очень внимательным, если вы запускакте разные тесты в одной программе подряд: результаты работы одного теста могут повлиять на остальные.

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

Нужно. Назови это чем-то типа "анализ и уточнение технического задания, и составление плана работ " назначь цену изходя из размера ТЗ и количества необходимых созвонов и доработок.

Дай скидку, если в итоге решите сотрудничать.

В случае возражений - проведи аналогию с реальным миром: замер окон, геодезические работы перед стройкой, итд.

Если скажет что другие исполнители не берут деньги за это - напомни про скидку и скажи, что это тоже работа и оно позволяет точнее предсказать цену и, меньше затягивать сроки, и не делать лишних правок ближе к концу проекта.

Добавить start """ """

runas.exe /user:admin /savecred "cmd /C start """ """ """C:\Program Files\Corel\CorelDRAW Graphics Suite 2022\Programs64\CorelDRAW.exe"""

В вашем рассуждении ошибка в том, что вы не домножаете условную вероятность 2/6 на вероятность условия. Вы же полную вероятность считатете а P(A) = P(A|B)*P(B)+P(A|!B)*P(!B). У вас P(A|B) = 0, как вы заметили - если они встретились в первом туре, то во втором уже не встретятся. Но все-равно надо 2/6 домножать на P(!B) - вероятность того, что они не встретились в первом туре. А это 1-1/7 = 6/7. В итоге получается все то же 2/6*6/7=2/7.

Но рассуждения автора проще. Можно рассмотреть все независимые элементарные исходы "где в сетке оказался второй игрок". Их 7, они равновероятны по симметрии. Дальше надо домножить на вероятность, что они начиная так встретятся (выиграют свои матчи).

А вы сами то открывали файл по ссылке из data.git_url?
Там отдаётся JSON с файлом, закодированным в Base64.
В Base64 каждые 6 бит исходного файла кодируются одним символом (8 бит) текста, а после каждых 60 символов добавляется символ переноса строки. Вот и получаем ~ (2/6 + 8/360) = 35.6% дополнительно к объёму.
Если хотите получить файл сам по себе, то используйте поле download_url.

Сделай снова git clone с remote.

const char* взялся вот отсюда: "Hello world". Это строковая константа в коде. Ее программа менять никак не может. Компилятор ее засовывает в read only секцию исполняемого файла.