res2001

Квант времени - это время в течение которого ОС позволяет работать потоку (процессу) непрерывно. По истечении времени, поток вытесняется другим. Когда настанет очередь опять выполняться этому потоку (процессу) ему снова будет предоставлен 1 квант времени. Так что переживать о том, что не хватит времени - не стоит - время всегда будет дано, пока процесс работает.
Квант времени в разных ОС разный, обычно это что-то в диапазоне 1-10 мс. В Линуксе квант динамический, вычисляется на основе приоритета процесса - чем выше приоритет процесса, тем больше ядро дает ему работать.

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

может ли теоретически возникнуть ситуация, что из-за нагруженности какой-нибудь процесс будет успевать только регистры восстановить, и ничего полезного не сделает, то есть будет постоянно нулевая работа за этот промежуток времени?

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

какой из вариантов наиболее эффективен / наиболее используемый

Создание класса в динамической памяти делится на 2 этапа:
1. выделение "сырой" памяти у менеджера памяти
2. инициализация памяти - вызов конструктора класса на выделенном участке памяти.
Вариант с malloc не выполняет вторую часть. Для того что бы закончить процесс в этом варианте вам надо использовать размещающий new, передав указатель на ранее выделенную память. Деструкторы так же нужно будет вызывать явно.

Если вариант с malloc довести до логического конца, то он будет делать то же самое что и вариант с new, никаких преимуществ тут нет. Но не забываем про явный вызов деструктора.

При удалении класса из динамической памяти присутствуют обратные этапы: вызов деструктора и освобождение памяти.

malloc обычно используют в плюсовом коде, когда реализуют собственные аллокаторы и нужен "сырой" не инициализированный блок памяти. Но и в этом случае вполне можно обойтись без malloc - использовать new char[MEM_SIZE]

Не нужно ставить микротик у провайдера, купите в головной офис статический белый адрес и микротик поставьте у себя. Впрочем даже микротик не нужен, зависит от того где вы сейчас осуществляете маршрутизацию филиалов, возможно, ВПН можно поднять там же, это было бы удобно.
Кстати, я бы и филиалы, которые работают по VLAN оператора завернул бы в ВПН - так безопасней. Хоть трафик и не гуляет по интернету, но его видит оператор. Нужно ли это бизнесу?

Нужно делать цикл по исключаемым файлам и исключать файлы по одному.
В make для этого есть $(foreach ...)

KR не учебник и не стандарт, написана давно. Хотя есть довольно свежее издание, но текст не изменился.
Берите Эффективный Си, хотя я не читал эту книгу, но выглядит норм. К тому же написана на основе свежих стандартов, в отличии от KR.
У вас не плохой бэкграунд, сам язык достаточно прост, разберетесь с тонкими местами (массивы, строки, динамическая память, указатели, адресная арифметика) и можно начинать что-то делать.
По функциям стандартной библиотеки полно информации в интернет, например тут
Вообще книг на русском именно по Си не много, возможно это связано с тем, что язык достаточно прост и одна хорошая книга закрывает большую часть потребностей.
Кстати, "экстремальный Си" выглядит то же многообещающе, но это, похоже, уже следующий уровень.

Заверните весь код в input.cpp в namespace input {}
namespace добавляет к символам в объектом файле имя namespace, но т.к. у вас определения в input.cpp не включены в namespace, то в объектном файле эти символа будут без добавления имени namespace, поэтому и undefined reference.

Если говорить о скорости, то компилируемые языки всегда будут быстрее интерпретируемых. Просто из-за разных принципов выполнения программы.
Есть еще языки с JIT компиляцией, типа Java, C# и т.п.
Они могут быть быстрее компилируемых в каких-то случаях, т.к. они точно знают на каком процессоре работают в каждом конкретном случае и могут максимально использовать возможности текущего процессора для оптимизации кода.
В компилируемых языках, как правило, программист собирает программу под некоторую абстрактную архитектуру, например под x64, но у конкретного процессора, на котором будет выполнятся программа могут быть какие-то расширенные возможности, о которых программист (компилятор) не знает во время компиляции (или решает не использовать их для универсальности). При этом JIT компилятор может использовать эти расширенные возможности и добьется лучшей производительности.
Но если поставить в одинаковые условия компилируемые языки и языки с JIT компиляцией, то, думаю, результат будет то же в пользу компилируемых языков. Но в реальности такое (заранее известные условия исполнения для компилируемого кода) встречается не часто.

К слову, в том же питоне (интерпретируемый язык), например, модули для математических вычислений (numpy, scipy, ...) написаны на компилируемых языках (C/C++), поэтому они работают быстрее, чем аналогичный код на питоне без использования этих модулей. Да и сам интерпретатор питона написан на компилируемом языке :)

Скорость не единственный критерий для ЯП. Имеет значение и скорость разработки конкретной задачи и поддержка каких-то возможностей и т.д. и т.п.

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

Практически все задачи можно решить почти на любом ЯП, но есть ЯП, которые хорошо подходят для решения задачи, а есть те, что не очень. В общем, подбирайте язык под задачу.
Например, если вы работаете в вебе, то это JS, php, python, java, C# и еще пачка других
Если это десктоп приложение с GUI, то: Java, C# может быть С++
Если это встраиваемая техника и реальное время, ядро ОС или драйверы: C/C++
Если это ИИ, компьютерное зрение и т.п. computer science: python, R, что-то еще

1. Размер всех типов всегда кратен 8 битам. Просто потому, что минимально адресуемый размер памяти в современных процессорах - это 1 байт. Так что 31 или 33 сделать не возможно. Теоретически можно сделать, например, 24 или 40, но смотри следующий пункт.
2. Все базовые типы С/С++ однозначно проецируются на типы данных, поддерживаемые процессором. Поэтому реально использовать только типы, которые поддерживаются железом. А их не так много и все они, скорее всего, уже есть среди базовых типов С/С++.

Да можно использовать вариант с битовыми полями или библиотеки для длинных чисел и т.п., но вычисления в этом случае будут медленные, т.к. все операции придется реализовывать программно. Кроме того, если взять битовые поля - там вы можете определить поле размером в 31 бит, но переменная все равно будет занимать 32 бита в памяти (см п.1).