Когда приложение работает ~месяц в >60 тыс потоков, 2% это дофига

По работе приходилось сталкиваться. Впечатление не очень, потому что весь код, который я видел, был без комментариев, документации нет, а в случае чего оно ломается с "derivation failed" где-то в недрах этой бездны. А, да, ещё я при помощи nix-garbage-collect раз в два месяца сношу 30 Гб разного добра. И потом час сижу, жду пока nix соберёт очередной набор из binutils и всего-всего для рабочего проекта.

Не за что. Кстати говоря, Вы знакомы с языком Nix? То, что Вы рассказываете очень мне про него напоминает...

Я не про менеджер пакетов, а про язык - его синтаксис, семантику и реализацию. Кажется очень похожим на то, что Вы делаете.

Да, довольно похоже

Это если оно только в release-сборке занимает час. Но типы не зависят от билд-конфигурации, и получается что в таком случае каждая сборка будет занимать час

Ну и ладно. 2% это ускорение больше чем на час

А насколько это замедлит разработку?

А зачем всегда собирать с полной оптимизацией?

-О0 хватит всем. А надо больше - ну потерпим

Вспоминается фраза, что нужно работать не 24 часа в сутки а… головой, у американцев есть еще «work smarter not harder».
Я к тому, что опитизация алгоритмов может дать буст в n^2, n^3 или n! раз (кстати сюда можно привлечь и SMT решатели но лишь для симлификации формул / уравнений к примеру), выбор правильного языка / компилятора от 1-700 раз (сюда можно отнести SIMD-автовекторизацию и автоматическое распараллеливание), Profile-guided optimization - может еще дать 10-30%. Peephole оптимизации через souper дают вот эти самые 1-3%. Ну как бы капля в море не считаете?

Я привык на мысли про "каплю в море" или "измерительной погрешности" замечать, что 2% -- это целая лишняя неделя датацентра в год. Да, за такими улучшениями в проектах, где выработано уже всё лёгкое, гонятся. Кто считает обратное, пусть кладёт обратно свой месячный оклад за каждые четыре года стажа :) Плюс-минус же, мелочи.

Ну и если прям вообще производительность стоит во главе угла, то лучше задуматься о переносе всего что можно на CUDA или специзировать все на FPGA

Самые медленные операции в таких задачах как работа с сетью или BD - это IO, а так же системные вызовы. Перенос всего на Ring 0 (микроядро) даст куда более заметныйй эффект, чем оптимизации ALU / FPU (числодробилки), не находите?

Да уж ладно, в JVM работой в оптимизирующих компиляторах никто б не запаривался в таких условиях. Но нет, производительность "чистого" кода ещё как важна, без I/O и прочей системщины. Там за единицы процентов на больших ворклоадах медали раздают. А переносить 10 мегастрок энтерпрайзного мишшн-критикал кода на FPGA, GPU, да и в нулевое кольцо -- это "безумству храбрых поём мы песню" ;)

Во всяких уже и так виртуализированных системах так и делают, те же includeOS и аналоги

В JVM запариваются потому что он создавался для managed ЯП (Java) у которой почти все вызовы виртуальные, а ООП абстракций в коде обычно столько, что любой другой язык бы уже кони отдал=) Кстати в AOT Java компилируется весьма паршиво как показывает GraalVM

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

Вот! Вроде чатик про компиляторы, пора разобраться, за что "на самом деле" компиляторщикам деньги платят :D

Это объясняет, зачем изначальное инвестирование нужно, но не объясняет текущую разработку. Ну ок, JIT получил скорость в 20х больше, чем прямая интерпретация. Всё, остановились? Нет, крутят дальше оптимизации.