> Я решаю задачу максимально быстро,
> используя все фишечки баша,
> это нормально для баша -- пересылать одни и те же байты ... тысячу раз

Эмм, ты нашёл какие-то таблетки от когнитивного диссонанса? Или как тебе удалось, при подобном уровне внутренних конфликтов, избежать принудительной изоляции от интернета?

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

Если же тебе важнее результат, а не олдскульность решения, и бигдата тебе неинтересна, то, реально, глянь на python или Go. Их освоить проще чем bash, и они в отличие от bash заточены на то, чтобы обрабатывать данные в памяти. Баш хорош только для того, чтобы вызывать другие программы, которые будут обрабатывать данные в памяти.

> гигабайт чисел можно сложить в баше очень быстро, или можно сделать это значительно медленней сотней способов

Эмм... Я не думаю, что можно сделать медленнее чем в баше. То есть понятно, что скорость упрётся в скорость используемой реализации чисел произвольной точности, но либо bash не повлияет существенно на скорость, либо он её снизит. Если точный результат не нужен, то можно попробовать разбить гигабайт на килобайты, каждый сложить в отдельный float, получить миллион флоатов, разбить их на куски по 1000 флоатов, просуммировать каждый, получить несколько сотен флоатов и уже сложить их -- точность результата будет не фонтан, но по-крайней мере не придётся упереться в насыщение, когда добавление очередного положительного числа к сумме не меняет сумму. Но это варианты не совсем для bash'а: можно извернуться при помощи какого-нибудь там parallel, чтобы удобно разбивать задачу на подзадачи, да ещё и все ядра задействовать при этом, но проще и быстрее написать на C, и результат будет быстрее. Хотя если связаться с pthreads и раскидывать задачи по потокам, то сумма времени написания кода и выполнения его скорее всего окажется больше, чем в случае с bash и parallel.

> 20 секунд превращаются в 12 пересборкой одного jq (или сменой компилятора который его собирает, лол) [...] сравнил на кейсе, который достаточно медленно и печально отрабатывает

Если у тебя есть возможность выложить этот интересный кейс, чтобы я мог бы его воспроизвести, то я буду очень благодарен. Реально интересно: я подозреваю, что это глупость какая-то, то ли в ./configure, то ли ещё где-то. Но не факт: я бы скорее ожидал, что глупость такого рода будет давать пенальти к производительности при использовании llvm, потому как он менее популярен.