> На фоне вышесказанного тобой, эти цитаты нерелеванты -- они не могут объяснить
> зависимость от языка, потому как они на том же уровне абстракции,
> где и моя ссылка выше.Зачем мне С или С++ если "оптимальности" ради я должен втыкать в асм (как вы советуете в комментах выше)?
На веру разве не принимаем, что компилятор сгенерит "оптимальный" код? Нету "сильной зависимости от языка", ибо требования "оптимальности" необходимо строго определить. Выбор ЯП тут относится больше к первому пункту, а может и вовсе не относиться.
> Хочешь я сравню printf из C и println! из rust'а? В rust'е
> println! разбирает форматную строку на этапе компиляции, чтобы потом в динамике
> при каждом вызове этого println! не парсить её заново. В C
> этого не происходит, как ты думаешь, почему?
И хочется спросить, что в роли "оптимального" критерия в этом случае используется? Опять бежим смотреть какой из компиляторов сгенерил оптимальный код для одного и того же алгоритма? Отсюда значить делаем вывод, что С "оптимальней" Раста, или на оборот? Если да, то тогда зачем нужны эти С и Расты, если можно по дефолту писать "оптимально" на асм?
> Моя теория, что это из-за того, что в C нет ни макроязыка,
> ни константных функций, которые можно выполнять на этапе компиляции. Поэтому в
> C, чтобы получить разбор форматной строки на этапе компиляции, придётся писать
> специально заточенный препроцессор. Всем на это плевать, и поэтому если в
> C реально нужна скорость вывода, ты будешь в процессе оптимизации заменять
> printf'ы на вручную записанную последовательность вызовов типа:
> print_string("Size is ");
> print_int(x);
> print_string("Mb\n");
> ...
еще и буфферизацию вывода учтите )
> Это вряд ли понадобится, потому как printf это как правило к выводу,
> а ввод-вывод тормозит больше парсинга. Но всё же.
> Или возьми async/await, и прикинь каково выбрать архитектуру программы с async вызовами
> лямбд, если твой язык -- это C. Для пользователя языка, в
> котором есть async/await использовать их -- это вполне себе опция доступная
> на этапе принятия решений об оптимальной архитектуре программы.
А не на С тот же async/await написан?
> Для пользователя C
> это конечно опция, но она будет сопряжена с таким количеством проблем,
> что лучше её опустить для ясности.
Именно пользователя, если нет готового решения - нах не нужен.
> Есть другие способы асинхронно выполнять
> код, плюс можно немного пожертвовать latency, и если быть осторожным и
> внимательным, то не получить залипаний программы на несколько секунд.
Асинхронность и залипания - мысль не ясна, уточните.
> Тебе нужны ещё примеры, или трёх хватит?
Желательно на асм, я не хочу "сильно зависеть" от ЯП уровнем выше.
> Какой из них и когда лучше?
Вот когда будут строгие критерии "оптимальности", тогда и получите ответ. При одних критериях будет один лучше, при других другой. Вы приводите примеры, но я не вижу критериев.
