А о каких программах на го речь-то? Просто на го

обычно пишут всякие сетевые штуки - и упарываться в оптимизацию гошного кода обычно даже смысла не имеет, т.к. всё сжирают сетевые издержки и запросы к БД

о цпу-баунд, очевидно. Можно, конечно, быстрее ждать данные

Сетевой код очень разный бывает.

Например, dns-серверу совсем не нужна бд, но надо уметь очень быстро посылать/отправлять/формировать пакетики. Или вот подумайте про реализацию quic на go, где из/в стека udp-пакеты, а вся машинерия происходит уже в гошном коде.

кстати, а в нет/хттп своя реализация квика?

Ну, в таких программах - да

Да, как и просто http2, который получился с "особенностями"

ну хттп2 то неинтересно, он использует тот же низлежащий транспорт. А какие у него особенности?

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

И других вариантов особо нет. Потому что либо тягать жирные куски asm, либо cgo.

ждем дешевый cgo, да

ну с cgo есть шанс, что накладные на его использование превысят выигрыш

Стримы поверх одного соединения. Что в конкурентной среде приводил к локам(сокет то один и потому нужна синхронизация). В golang-nuts приходили с жалобами что http2 в разы медленнее чем http1.1

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

но любая thread-safe реализация в лоб будет медленнее, как мы понимаем

В каком-нибудь языке с async/await ты точно знаешь что у тебя не отберут управление в неожиданных местах и ты не проснёшься на другом треде. Потому там не надо лочиться.

https://t.me/gogolang/860858

это ровно то, что я сказал, что лько другими словами 🙂

Вообще говоря не знаешь

Не в tls дело. Фрейминг в http2 идёт до tls(если смотреть сверху вниз). Проблема в том, что мы можем писать в стримы из разных горутин(и вот тут нужна синхронизация). А потом уже идёт tls и после кормится в сокет.

wireguard-go с udp выжимает 6-7гбит, ядерный wireguard упирается в 3гбит

Это интересно, кстати Ядерный просто однопоточный?

И это хороший пример что перенос кода в ядро не обязательно даёт ускорение :)

Нет, ядерный параллелится

там нет некоторых оптимизации вроде tso/gro, а проблема передачи большого количества пакетов решается recvmmsg/sendmmsg они в го поддерживаются, или uring, он пока не сильно удобно поддерживается https://tailscale.com/blog/throughput-improvements/

Ну по факту, там очевидное: 1. процессить надо пачками 2. отправлять/получать - пачками

Спасибо!

И gso/gro. tso - это про tcp :)

tso тоже важен, позволяет внутри тунеля выкрутить MSS в большие значения, и пересегментировать только на выходе в WAN

Эээ... Там вроде иначе. В tun пишется/читается жирный кусок внутри которого пачка пакетов(+спец. заголовок на каждый пакет). Через флажки такой режим включается и это позволяет за 1 сисколл отправить/получить много пакетов. Оптимизацию изначально делали для kvm.