C — современный asm, потому что буквально можно глазами транслировать в ассемблерные инструкции

А если хорошо понимать, что происходит во время вычислений, то компиляторные интрисики в помощь

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

Где-то там была лекция с cppcon про оптимизацию qsort руками

тоже далеко не факт. смотря сколько времени человек готов потратить.

час на команду? допустим. Но даже самые дешевые микроконтроллеры держат около 10к команд.

Да, знаю. Но ведь бин состоит не только из твоего кода. Гсс ещё накидывает

Там обычно всякий startup оверхэд же, который, при желании, можно и самому написать :)
Или я не так понял?

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

Хочу питон компилировать(

Во что?

exe/линёвые исполнимые/mac/нейтив/gpu

Полный фарш, так сказать

Так есть трансляторы питона в llvm-ir. Компиляция в нативный код.

Да нет, gcc сильно не кидывает. Результирующий бинарник в десятки килобайт, с зависимостью от небольшой динамической libc.
А вот C++ с STL увеличивает размер бинарника, но я бы не сказал что сильно.
А вот приложения скажем, на Flutter/Dart получают весьма значительного размера, когда HelloWorld на Flutter потребляет около 100 Мегабайт оперативной памяти пропадает желание программировать на этом, потому старый добрый C/C++  на этом фоне представляется отличным языком программирования.

Нее, есть только Numba, которая ускоряет матешу через LLVM

В век гигабайтов оперативки и терабайтов HDD тебя парит размер бинарника?

Библиотеки на Go компилятся под arm и подключаются как .aar/.framework. А gui накидываются на flutter.
Можно и все на Dart пилить, но мне Go ближе. Есть также у него gomobile, но оно такое себе

для ai всёже питон получше будет

что скажете про rust/go?

У меня есть внутреннее API, которое нужно заприватить. Доступ только у клиента (в нашем случае другой веб сервер). Насколько безопасен такой подход? API ключ есть у двоих сторон, хранится в ENV. При первом запросе после рестарта серверов требуется лишь токен, потом требуется session, который сбрасывается после каждого запроса. Session так же хранится в ENV, отдаётся обновлённым клиенту, если API ключ совпадает. Клиент его тоже кладёт в ENV, отправляет обновлённый session и токен в body каждого запроса, токен обновляется снова, и так по кругу