Или это 2 параллельных чата, и админы не связанных друг с другом? Спасибо.

Там как-то больше новичков и флуда)

да блэт.. заблокируйте его

это разные все время

я каждого блокирую и сношу сообщение

тогда вообще печально..

но, вообще, я уже готов начать агитацию за закрытие этого чата

почему?

но, вообще, я уже готов начать агитацию за закрытие этого чата

в пользу какого?

например - перевести всей участников в RO

в пользу какого?

https://t.me/gogolang

там жив создатель, и можно ставить ботиков

там жив создатель, и можно ставить ботиков

Но и темы там попримитивней :(

не уверен

главное сообщество а не название чата) перейдут люди, будут тож самое обсуждать

главное сообщество а не название чата) перейдут люди, будут тож самое обсуждать

:)

но, вообще, я уже готов начать агитацию за закрытие этого чата

я тоже с момента пропажи продота как-то всё чаще склоняюсь к тому, что это имеет смысл

Когда переезд?

Да там и так одни и те же люди.

Да там и так одни и те же люди.

ну и зачем тогда чат, где нельзя даже ботов добавлять для упрощения изни одменам?

ну и зачем тогда чат, где нельзя даже ботов добавлять для упрощения изни одменам?

он вроде наоборот хотел сказать, что переезд не будет кровавым

он вроде наоборот хотел сказать, что переезд не будет кровавым

вообще о кровавом никто не говорил %)

ну и зачем тогда чат, где нельзя даже ботов добавлять для упрощения изни одменам?

Я про то, что и перводить людей то особо и не надо.

Я про то, что и перводить людей то особо и не надо.

ну - сообщение оставить надо же

так чё, merge? @onokonem вроде и не против никто

я за

не сейчас

вечером

только как ты без ботов в РО 1700+ человек закинешь?

через клиентское апи полезешь?

через клиентское апи полезешь?

Кстати, кому-то удавалось flood prevention обойти?

Кстати, кому-то удавалось flood prevention обойти?

вообще таким не занимался

а кто-то сравнивал скорость индексной арифметики по слайсу и адресной арифметики?

Я так понимаю что стоит просто закрыть этот чат и все просто туда перебегут. Или его нет возможности закрыть?

а кто-то сравнивал скорость индексной арифметики по слайсу и адресной арифметики?

я планировал, но там очень много кейсов, стало как-то лень

Я так понимаю что стоит просто закрыть этот чат и все просто туда перебегут. Или его нет возможности закрыть?

создатель чата пропал неизвестно куда

я планировал, но там очень много кейсов, стало как-то лень

у меня все довольно банально: есть кусок памяти в котором лежат структуры. я могу через slice header сделать слайс, а могу адресной арифметикой бегать по этому. интересно, что быстрее.

вот кстати! почему вместо этой микрооптимизации ты просто не докинешь ядер?

у меня все довольно банально: есть кусок памяти в котором лежат структуры. я могу через slice header сделать слайс, а могу адресной арифметикой бегать по этому. интересно, что быстрее.

По слайсу бегаете последовательно?

Range-м?

у меня все довольно банально: есть кусок памяти в котором лежат структуры. я могу через slice header сделать слайс, а могу адресной арифметикой бегать по этому. интересно, что быстрее.

Должно быть плюс-минус идентично

вот кстати! почему вместо этой микрооптимизации ты просто не докинешь ядер?

Мне в конце концов не хватило докидывания ядер

Вообще в машинных командах от силы добавится один такт, но опять же он может быть запаралелен и это на фоне занимаемого времени обращения к памяти - мизер.

Мне в конце концов не хватило докидывания ядер

так может быть, но я бы хотел увидеть цифры

так может быть, но я бы хотел увидеть цифры

Почему ты не спросил меня об этом n времени назад?)

По слайсу бегаете последовательно?

нет, просто по индексу, без range.

вот кстати! почему вместо этой микрооптимизации ты просто не докинешь ядер?

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

нет, просто по индексу, без range.

Рэиндж скорее всего использует инкремент адреса. Если последовательно индекс инкрементируется, то оптимизатор может оптимизировать (есть ли только он в Гоу).

Рэиндж скорее всего использует инкремент адреса. Если последовательно индекс инкрементируется, то оптимизатор может оптимизировать (есть ли только он в Гоу).

окей, попробуем написать бенчи )

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

вот я что-то такое подозревал. что тебе просто лень сделать как следует :)

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

ты пишешь что-то типа DPI под большие нагрузки (аля 10G) в user space?

ты пишешь что-то типа DPI под большие нагрузки (аля 10G) в user space?

да

я не супер эксперт в этом, но кажется нутро цисок не на го пишут и не в user space

вот я что-то такое подозревал. что тебе просто лень сделать как следует :)

нет, просто все ради локальности.

Меня недавно звали в контору одну пилить такой dpi, но оказалось, что у них денег нет %)

я не супер эксперт в этом, но кажется нутро цисок не на го пишут и не в user space

https://github.com/intel-go/nff-go

https://github.com/intel-go/nff-go

"Easily leverage Intel hardware capabilities: multi-cores"

кек?

"Easily leverage Intel hardware capabilities: multi-cores"

У интела мультикор сделан не так, как у амуде, но звучит комично, да

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

я не супер эксперт в этом, но кажется нутро цисок не на го пишут и не в user space

как буд-то это важно в 21-ом веке

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

это вы лично меряри, или в интернете начитались?

"Easily leverage Intel hardware capabilities: multi-cores"

да, потому что это обертка на dpdk.

это вы лично меряри, или в интернете начитались?

"я не супер эксперт в этом" -- я написал это несколько сообщений назад

пара милисекунд - это очень много для gc

это вы лично меряри, или в интернете начитались?

Человек же пишет — "я думаю"

это вы лично меряри, или в интернете начитались?

нет, просто я прокекал над тем, что в цисках наших IX будет GC триггериться вместо того, чтобы трафик гнать

где линки аля 10/40G

можно, конечно, как убер, написать такое, что и на секунду замрет, но моно же и не писать!

пара милисекунд - это очень много для gc

У меня некоторые криптографические функции столько отрабатывают, какой gc, вы чё

можно, конечно, как убер, написать такое, что и на секунду замрет, но моно же и не писать!

о, а можно примеров что убер такое пишет

нет, просто я прокекал над тем, что в цисках наших IX будет GC триггериться вместо того, чтобы трафик гнать

в большинстве задач очень трудно померять паузу gc - настолько она мелкая

о, а можно примеров что убер такое пишет

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

где линки аля 10/40G

причем тут скорость линков?

в большинстве задач очень трудно померять паузу gc - настолько она мелкая

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

причем тут скорость линков?

теоритическое количество пакетов, предполагаю, зависит от скорости

теоритическое количество пакетов, предполагаю, зависит от скорости

допустим. и что? для того чтобы замечать gc надо иметь очень много поинтеров.

допустим. и что? для того чтобы замечать gc надо иметь очень много поинтеров.

Я не знаю, что такое "очень много", но, вероятно, это описано в спеке go gc. И мне интересно посмотреть на код и практики, который не создает ни байта мусора. Я не на вашем месте, требований 100% к продукту не знаю и ваш выбор -- это ваш выбор. Просто продакшен решение, которое нельзя даже вертикально замасштабировать ("докинуть ядер") и требует супер хаков -- выглядит странным, как по мне.

коллега, я не знаю, кто вас так напугал gc, но он для 99% приложений не создает вообще никаких проблем

мусор собирает незаметно

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

может быть, в SLA прописаны гарантии по latency/QoS

а может быть и нет -- никто не знает ?

у меня проблем с GC ни в го ни в джаве нет

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

ты тогда скорее упрёшься в откровенно говняные DS в рантайме и в блокировки, чем заметишь gc

да

но есть узкий класс задач, где именно в gc можно упереться

потому убер везде и рассказывает об этом

до того, как упрёшься в то, что в языке куски говна вместо DS?

прямо скажем, я не знаю ни одного многопоточного языка, где не мог бы назвать все (или почти все) DS кусками говна