Присоединяйтесь к моему каналу в Телеграм: t.me/vladimir_balun_programming
@denissemikin2683
5 ай бұрын
Данная логика с оптимизацией хорошо рассписана в книжке «100 ошибок Go и как их избежать» в последней главе.
@martirosharutunyan6572
5 ай бұрын
Ну брат ну ты даёшь это всё очень круто. Думаю всем будет уроком немножко процессор и память изучить.
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@viktorkram2531
5 ай бұрын
Крайне интересная информация, спасибо! Коротко и очень необычно) Спасибо!
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@beast0608dihdbdn
5 ай бұрын
Вова, ты крут, очень понравилась данная рубрика, спасибо!)
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@AleksandrRasskazov
5 ай бұрын
Приятненько. Это похоже как и на порядок полей в структурах
@nikolaykozlov4888
5 ай бұрын
Млин, Вов, как всегда - огонь!!!
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@czm41k
11 күн бұрын
Очень круто, спасибо
@theprogrammer256
5 ай бұрын
Круто! Вы фокусник! ))
@sovrinfo
5 ай бұрын
Спасибо, очень интересное видео!
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@henrytavilla
5 ай бұрын
Спасибо за крутой лайфхак! Полезно 😊
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@amb7048
5 ай бұрын
Какие вы ресурсы изучали чтобы знать тонкости всего процессора и библиотек языка? Вы настолько детально все изучили, что как будто бы вы с другой планеты) Было очень интересно!
@vladimir_balun_programming
5 ай бұрын
Я не знаю очень много всего все еще - а то, что знаю, просто последовательный путь изучения тем, которые постепенно друг с другом переплетаются)
@azizmavlyanov3145
5 ай бұрын
Владимир, как обычно, топ-темы рассматриваешь. Очень хочется увидеть и поработать с такими необычными темами и на твоем курсе по concurreny в go. За данный видос огромный респект!
@vladimir_balun_programming
5 ай бұрын
Спасибо, курс как раз будет 2 мая - там в том числе и это разбирается)
@itkrasavchik
5 ай бұрын
Прикольно ) Красавчик! ;)
@alekseevserge
5 ай бұрын
Осталось только коммент в коде написать, чтобы другой программист не грохнул неиспользуемую память)
@vladimir_balun_programming
5 ай бұрын
Хорошее замечание)
@nikmy_
5 ай бұрын
Очень известная штука в профессиональных c++ кругах. Если вместо sequential consistency бахнуть acquire-release семантику, вы ускорите ещё раза в 3-4) Но в го отказались от такого для простоты (см. go memory model). Очень подойдёт тем, кто занимается разработкой чего-то низкоуровнего, я сам был в шоке когда увидел в первый раз такие оптимизации)
@thegeneralopinion9713
2 ай бұрын
почему цикл не в самом начале функции benchmark? for j := 0; j < b.N; j++ {
@__kawaii
4 ай бұрын
Как ты вообще додумался до этого? Мозг капитальный. Постфактум, конечно, кажется очевидным, но изначально к этой мысли бы никогда в жизни не пришел самостоятельно
@lmorozkol
5 ай бұрын
чудеса на виражах прям какие-то)
@vladimir_balun_programming
5 ай бұрын
Магия)
@vladislav_artyukhov
3 ай бұрын
На превьюшку поставить: _ [60]byte ↖ Это увеличит скорость кода в 10 раз
@vladislav_artyukhov
3 ай бұрын
Цыганские фокусы
@БорисКрасных-ц8н
4 ай бұрын
Да, Балун реально шарит, мощь. Нетривиальный ролик. И классный пример того как понимание подкапотной работы помогает реально оптимизировать код...
@unciauncia
5 ай бұрын
А какие минусы у такой оптимизации? Получается, что мы резервируем себе участок памяти кэша в котором полезных данных 4 байта, а всё остальное не используется никак? Как будто это оптимизация будет сильно отъедать память, когда количество горутин будет значительно больше, чем число ядер, и тогда относительно не быстрая зашаренные данные, будут эффективнее по памяти, но медленнее исполняться. Вопрос какой баланс в итоге лучший, всегда по ситуации?
@stupnum8764
5 ай бұрын
Нуу, 64 байта это очень немного. L1 кеш на большинстве современных процессоров имеет объем 32kb, соответственно туда поместится 512 таких переменных на одно ядро, но насолько я понимаю при работе в одном потоке процессор не будет загружать в себя данные всех переменных, хотя это под вопросом. Я думаю если протестировать данный лайфхак на большом количестве корутин, то получится что он все равно будет значительно быстрее, чем без этого приема. Хотя не уверен, надо бы протестировать.
@sabbath359
16 күн бұрын
А если у нас куча других задач помимо счетчика, ? Могу быть не прав, но это звучит так как будто в вакууме это финт ушами уровня магистра, но если взять реальный сервис, который, условно, съедает 70% ресурсов машины, ? Или еще лучше рассмотреть ситуацию , когда запросов настолько много, что условный сервис должен ?
@ТимофейЁлкин-о9е
5 ай бұрын
Супер! Респект и удачи тебе!
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@kostya7469
5 ай бұрын
Очень интересно! спасибо
@vladimir_balun_programming
5 ай бұрын
Спасибо!
@АнтонИцкович-х7у
5 ай бұрын
ШИКАААРРРРРРНООО!!! брат давай такие видео по всем темам и ты ТОП! такой шикраный контент и на русском
@dobermangood
5 ай бұрын
Круто! Не думал попробовать решить 1 billion row challenge на golang?
@sergiocoder
5 ай бұрын
В самом начале у нас вроде как у каждого ядра свой кэш, а после последней версии у всех ядер один кэш(-линия)? Или это разные кэши? В целом прикольная оптимизации, но насколько понял, ее эффективность зависит от конкретной архитектуры/модели процоессора, т.е. где-то можно не сработать. Хотя, если дело доходит до такой низкоуровневой ерунды, то наверное заранее известно, на каких процессорах будет запускаться код в проде )
@unlite2896
4 ай бұрын
Спасибо! Правда нет комментария, почему переход на атомики дал прирост в два раза. Просто потому что мьютексы медленнее атомиков? И по итогу нужно ли проводить шардирование для такой оптимизации, или достаточно просто выравнивания?
@nickolaizein7465
5 ай бұрын
Так выравнивание получается как бы "растягивает" счётчик на какое-то кол-во байт, хотя по факту их не использует, чтоб другой счётчик гарантировано попал в другую кэш линию ?
@sfdb97fsasdfasrewerwerzgdfgsda
5 ай бұрын
Желательно выравнивать к длине кешлинии архитектуры на которой запускается код, иначе оптимизации не будет, т.к значения будут затирать друг друга.
@rasZam
5 ай бұрын
Привет. Не подскажешь какой у тебя доп. монитор стоит?
@mordva756
5 ай бұрын
Это решение будет ускорять в 10 раз и при наличии другой работы в коде? Помимо инкрементирования счетчика, приложение делает ещё что-то и переменные тоже могут попадать в кэш. Возможно не очень понял, но мы как будто затрем весь кэш при инкрементироварии счётчика таким способом и это замедлит код вокруг
@billjohnes9380
5 ай бұрын
Это если счётчик будет разбит на 1024 shard'а для 64K cache'а L1 или на 4096 shard'а для 256К. Пока на shard'ы тратится малый процент cache'а, такой опасности нет.
@io0312
5 ай бұрын
Можно исходники?
@denyskanunnikov7521
5 ай бұрын
добрый вечер, а есть ли публичный репозиторий с примером данного кода для более внимательного изучения? в записанном видео быстрое перемещение по коду и тем речи высокий, не всегда удобно для моментального восприятия
@КонстантинСердюк-ь5ю
5 ай бұрын
Есть курс по concurrency МФТИ , можешь посмотреть его , там 20+ часов :)
@denyskanunnikov7521
5 ай бұрын
@@КонстантинСердюк-ь5ю а ссыль можно, пожалуйста?
@profered
5 ай бұрын
ниче не понятно, но очень интересно
@billjohnes9380
5 ай бұрын
Попробуйте почитать мой большой комментарий-ответ другому собеседнику ниже про 64-байтные блоки адресного пространства. Возможно, что-то прояснится.
@МихаилИсаев-з2с
4 ай бұрын
Я так понял у Вас intel. Вот не могу, сколько не пробую, на M1 хак повторить, максимальной производительности добиваюсь при атомиках и дальше никак. Не получилось нагуглить как с кэш линией работает М1 Pro. Если у кого-то есть инфа, буду благодарен, потому что интересно повторить выравнивание на своем компе.
@thegeneralopinion9713
2 ай бұрын
Ты, наверно, просто тест с атомиками запускал. А надо шардированный тест со смещением структуры AtomicCounter
@НиколайВикторович-х3г
5 ай бұрын
Коротко о том как увеличить использование памяти приложения в 16 раз )
@НиколайВикторович-х3г
5 ай бұрын
@@doingwell5629 я имел ввиду в структуре 🙂
@vladimir_balun_programming
5 ай бұрын
@@НиколайВикторович-х3г это почти всегда компромисс - что-то получаем, чем-то жертвуя при этом
@alexandrlapin3641
5 ай бұрын
Подскажите , а на плюсах такие проблемы возникают?
@dmikoss
5 ай бұрын
Это актуально для всех языков, так как проблема завязана на принципах работы cpu
@vladimir_balun_programming
5 ай бұрын
@@dmikoss плюсую)
@silentroach
5 ай бұрын
Жаль что go не оптимизирует это сам на этапе компиляции
@roman_zh1
5 ай бұрын
Пушка. Наконец-то я понял зачем нужно знать устройство памяти и всего прочего, прям конкретный кейс, спасибо)
@vladimir_balun_programming
5 ай бұрын
Нужно не всегда, но иногда эти знания бывают очень полезными)
@timurakhalaya6289
5 ай бұрын
alignment это выравнивание , offset смещение) годный контент
@vladimir_balun_programming
5 ай бұрын
Все так)
@jin_x_
5 ай бұрын
Если уж придираться к неймингу, то такой заполнитель обычно называют padding.
@TomLeeGun
5 ай бұрын
это называется wet blanket) а если серьезно, то везде используется именно field alignment. учите матчасть!)
@XpIOHdeJIb3000
5 ай бұрын
зачем мьютекс на чтение? Какаю то ересь прочитать невозможно, либо текущее значение, либо текущее + 1
@vladimireliseev7602
5 ай бұрын
Забавно, возможно я что-то делаю ни так, но у меня все варианты не сильно друг от друга отличаются по производительности: BenchmarkAtomicCounter-10 10 1538 ns/op BenchmarkMutexCounter-10 10 412.5 ns/op BenchmarkRWMutexCounter-10 10 658.3 ns/op BenchmarkShardedAtomicCounter-10 10 570.9 ns/op BenchmarkAtomicCounterOptimize-10 10 775.0 ns/op
@MIRISU2
5 ай бұрын
я тоже попробовал проделать всё тоже самое. ShardedAtomic c alignment не сильно ушёл от Atomic и ShardedAtomic. 349.7 ns/op, 455.7 ns/op, 385.9 ns/op соответственно.
Пікірлер: 74