res2001

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

В C параметр функции не может быть массивом, только указателем. Синтаксис "имя с квадратными скобками" несёт тот же смысл, что и "имя со звёздочкой" когда речь идёт о параметрах функции. Если внутри функции взять sizeof от такого параметра результат будет равен sizeof от указателя. Это очень распространённая ошибка и компилятор говорит тебе об этом. Если тебе нужен размер массива переданного в функцию -- передавай его отдельно, например отдельным параметром.

sizeof(dict)/sizeof(const char)

Здесь ещё одна ошибка: dict -- это массив указателей (на самом деле указатель на такой массив, но по крайней мере, ты ожидал массив указателей), но ты делишь размер массива на размер const char а не на размер const char *. Во избежание таких ошибок для вычисления размера массива обычно пишут sizeof(dict)/sizeof(dict[0]).

Если записи фиксированного размера и отсортированы, а поиск идёт по префиксу, то никаких дополнительных структур не надо, достаточно двоичного поиска.

Два серверных файла конфигурации с разными портами и настройками пулов адресов и два соответствующих им клиентских файла конфигурации

можно подумать, что при объявлении указателя, символ * относится к имени(не как часть, а как что-то зависящее от него), а не к типу.

Если взять стандарт языка (например C99) и почитать главы Declarations, Type Specifiers и Declarators, то можно увидеть, что он разделяет declaration-specifiers, в который входят только слова и declarators, в который входят скобочки и звёздочки. Т.е. твой вывод по сути верный.

Там же можно увидеть, что часть называемую declarator всегда можно обернуть в скобки, из чего можно извлечь следующий вывод: часть объявления вокруг которой можно поставить скобки самым широким образом относится к конкретному идентификатору, оставшаяся часть -- ко всему списку. Т.е. const char *a, b; можно превратить в const char (*a), b, но нельзя превратить в const (char *a), b или в char (const *a), b.

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

Потому что 0.1 в двоичном коде не представимо конечным числом.
0.1₁₀ = 0.0(0011)₂
Записывая это число в 32-битовый float вы получаете 1.10011001100110011001101₂ * 2^-4 или 0.100000001490116119384765625₁₀
Соответственно, когда вы 20 раз прибавляете 0.1 к -1, вы не получаете 1. Вы получаете 1.000000298023223876953125₁₀.
Это число, очевидно, больше единицы, поэтому условие цикла не срабатывает и 21я строка не выводится.

Поискав в интернете

обычно там же рядом пишут причину, "дорогая" это операций на больших объемах данных, так что в процессе контакта, создают сессионный симметричный ключ (который в этом процессе сложно как-то перехватить) и дальше уже им с меньшими затратами можно шифровать
https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%B0%D...

Зависит от модели процессора, версии и опций компилятора и немножечко фазы луны. В целом без разницы.

Практический совет - лучше писать через индексы, ибо так понятнее и больше шансов что компилятор там все наоптимизирует (например, он сможет векторизовать работу через какие-нибудь SSE инструкции процессора).

Совет по бенчмарку - если памяти не хватает, стоит по одному достаточно большому массиву пройтись 10000 раз. А лучше использовать готовые фреймворки для измерения скорости, вроде того де gbenchmark.

Еще, иногда полезно посмотреть на ассемблерный выхлоп. Вот, например, что происходит при -O3 опции компилятора. Он генерирует вообще идентичный код для обеих функций (развернув циклы)! И даже при -O2 оно одинаковый код выдает.

Без оптимизаций код разный, но там все не так как вы думаете. Вместо инструкции mov eax, dword ptr [rax + 4*rcx] в варианте с индексами используется инструкция mov eax, dword ptr [rax] для указателей. Это самое "складывание с указателем массива" вообще не отдельная операция - а вариант адрессации в инструкции mov. Они могут вообще одинаковое количество тактов занимать, это надо мануал по конкретной архитектуре процессоров читать.

С какой ветки обновляет git pull?

С той удаленной ветки, которой соответствует ваша текущая локальная ветка

Когда в своей ветке я нажимаю git pull, то каким образом происходит обновление моей ветке?

Гит смотри на удаленную ветку и, если там есть изменения, подтягивает их

Например я создал текстовый файл в master и хочу, чтобы он появился в моей ветке, как это сделать?

Слить мастер в вашу текущую ветку

git pull не добавляет его?

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

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

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

Так что маршрут в 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.