YB
Могу сразу предельно точно пояснить, что вообще не смотрел никакой документации, кроме как пара предложений про хеши(и не собираюсь этого делать) и все вышесказанное чисто коммон сенс и наиболее часто используемые решения.
Size: a a a
2020 September 30
YB
Ну окей, может не коммон сенс, я такие штуки с детства фигачу, а последнюю дизайню уже несколько лет, так что, вероятно, прочитал примерно все, что по таким вопросам кому-то есть сказать, так что у меня может быть несколько искаженное восприятие мира.
YB
А протобаф - лютое говно, если что, ориентироваться на него вообще не стоит. (Хотя есть и намного хуже, конечно.)
k
А кто нибудь использовал rocket chat? Что это за фрукт такой?!
o
А кто нибудь использовал rocket chat? Что это за фрукт такой?!
примерно – аналог slack, только open source
AF
Я не настоящий лоулевелщик, не понимаю, зачем нужны varints. По их примеру 42000 кодируется 3 байтами, 24 бита, но этот же инт просто 16 бит (и очевидно это так до 65536). чтобы закодировать 2**32-1 им надо 5 байт (40 бит), но это же всего 32 бита. в чем профит?
видимо предполагается много мелких int, но и 4 байта хочется
SB
Я не настоящий лоулевелщик, не понимаю, зачем нужны varints. По их примеру 42000 кодируется 3 байтами, 24 бита, но этот же инт просто 16 бит (и очевидно это так до 65536). чтобы закодировать 2**32-1 им надо 5 байт (40 бит), но это же всего 32 бита. в чем профит?
В зависимости от предполагаемого использования каждый способ кодировки данных имеет как плюсы так и минусы (они там в табличке честно про это написали). Можно было бы везде в спецификации прописать жёстко, какая длина инта ожидается. Можно было бы даже везде использовать int64. Или всегда писать префикс типа. Они вот решили так. Возможно, ответом будет "потому что".
@
В зависимости от предполагаемого использования каждый способ кодировки данных имеет как плюсы так и минусы (они там в табличке честно про это написали). Можно было бы везде в спецификации прописать жёстко, какая длина инта ожидается. Можно было бы даже везде использовать int64. Или всегда писать префикс типа. Они вот решили так. Возможно, ответом будет "потому что".
На самом деле весьма здравая позиция.
SB
На самом деле весьма здравая позиция.
Мне в детстве тоже нравились хитрые алгоритмы упаковки - наверное, последствия раннего знакомства с низкоуровневым программированием, и то, что раньше ворды были байты. Теперь, когда я вижу упаковку данных, требующую много битовых операций, я понимаю, что это снижает производительность (немного), и не очень-то экономит память.
@
тут дело же не экономии памяти. это экономия передаваемых по сети данных. и (что гораздо важнее) расширяемость. в плане не надеяться на то что 64 бита хватит каждому
YB
Мне в детстве тоже нравились хитрые алгоритмы упаковки - наверное, последствия раннего знакомства с низкоуровневым программированием, и то, что раньше ворды были байты. Теперь, когда я вижу упаковку данных, требующую много битовых операций, я понимаю, что это снижает производительность (немного), и не очень-то экономит память.
Это повышает производительность (в подавляющем большинстве случаев)
YB
Потому что современные процы больше похожи на связанные по сети компьютеры, и производительность в основном строится из задержек и пропускных способностей. (Ну то есть оно всегда строится из них, но тут имеются в виду задержки вне арифметических юнитов.)
@
Ну такое утверждение. Спорное, мягко говоря.
YB
Ну такое утверждение. Спорное, мягко говоря.
Исключения бывают, но если говорить о софте в среднем (без каких-то прям массовых узких вычислений), то эмпирически оно так. Вплоть до того, что сжатие указателей(то бишь адресов памяти) с распаковкой на каждом обращении может быть быстрее, чем несжатие для достаточно широкого класса.
YB
Алсо, только косвенно относится к вопросу, но скомпилированный джс код имеет в себе огромное количество проверок соответствия переданных ему указателей на объекты прототипам, под которые оптимизированна единица компиляции, и на практике в очень большом количестве случаев это имеет ровно нулевой эффект на производительность (хотя и повышает энергозатраты).
KP
https://element.io/blog/gitter-is-joining-element/ хочется верить, что они купили его ради команды, которая может во фронтенд (Гиттер же и правда неплох в этом), и всё станет лучше через полгода-год
AF
https://element.io/blog/gitter-is-joining-element/ хочется верить, что они купили его ради команды, которая может во фронтенд (Гиттер же и правда неплох в этом), и всё станет лучше через полгода-год
фига ты жесткий
k
https://element.io/blog/gitter-is-joining-element/ хочется верить, что они купили его ради команды, которая может во фронтенд (Гиттер же и правда неплох в этом), и всё станет лучше через полгода-год
Хочется верить
b
zhoreeq [matrix]:
> <@bridge0bot:feneas.org> kirushik [telegram]:
> https://element.io/blog/gitter-is-joining-element/ хочется верить, что они купили его ради команды, которая может во фронтенд (Гиттер же и правда неплох в этом), и всё станет лучше через полгода-год
А что сейчас не так с фронтендом?
> <@bridge0bot:feneas.org> kirushik [telegram]:
> https://element.io/blog/gitter-is-joining-element/ хочется верить, что они купили его ради команды, которая может во фронтенд (Гиттер же и правда неплох в этом), и всё станет лучше через полгода-год
А что сейчас не так с фронтендом?
AF
кста