Полный перебор по слайсу всегда быстрее полного перебора по map, а не в каких-то специальных случаях. Даже без всяких кешей процессора, там же обвязка с рандомизацией. Если бы вопрос был наоборот - бывает ли перебор по слайсу быстрее доступа по ключу к map - и тут уже действительно ответ да в особых случаях, на map меньше 8.
большое спасибо за видео , уверен многим это будут на пользу ! Есть не большое но ) Уже не в первый раз слышу от Вас про кеш , тут многие ребята не с большим опытом - не хотелось бы искажать их представление о кеше в рамках систем дизайна 1) в большинстве случаев кеш это костыль , его надо применять очень осознано 2) в топку субд у которой реплики разъезжаются с мастером (ладно если пару раз все бывает и это можно устранить с помощью тулинга бд) 3)исходя из первого то костыль породит еще и синхронизацию которую надо будет реализовать валидацию, инвалидацию , нехватка памяти и.т.д Породит целую инфраструктуру которую надо поддерживать со своими отдельными проблемам ) Хорошо взвешенный выбор субд+архитектура избавит от кеша или очень сильно его минимизирует . А еще не совсем понятно от куда у большинства опыт в высоконагруженных проектах ?) у нас типа их пруд пруди ?)
Тоже было очень странно услышать про кэш в рамках такого вопроса. Вообще думал поднимуть вопрос САР теоремы а тут как будто кэш все проблемы решит. Так то тоже не ракрыт вопрос как инвалидировать кэш после обновления БД и какие механизмы для этого использовать. Т.е. от той самой проблемы задержки между обновлением и репликацией/инвалидацией мы никуда не ушли, только заменили одну на другую... Кэшировать то как раз таки лучше те данные которые редко меняются. Еще не разу не видел чтобы транзакционные данные хорошо поддавались хэшированию.
14:07 Интересно. Побенчмаркал, создал массив строк на 1000 элементов и мапу со строковыми ключами на 1000 элементов. Искомую строку поставил самым последним элементом массива (чтобы массив целиком прогонялся от первого до последнего элемента при поиске) Результаты: Поиск ключа в мапе: ~7ns/op. Поиск элемента в массиве перебором: ~700ns/op. Разница в 100 раз в пользу мапы. Думал, может с интами будет быстрее, создал мапу с интовыми ключами (в качестве значений struct{}{}) и массив с элементами типа int. Та же история, мапа ищет в ~100 раз быстрее. Сократил количество элементов до 100 (и в массиве и в мапе). Мапа перформит всё равно быстрее, раз в 50. Возможно массив на 5-10 элементов будет пробегаться быстрее мапы, не тестил, но и это вряд ли. Процессор i7 на MacbookPro. Да, массив влазит в кеш целиком и на каждой итерации происходит не обращение к памяти, а внутри кеша. Но, видимо, мапы в go оптимизированы так, что прогулка по поинтеру (на бакет) + прогулка по самому бакету (max 8 элементов по дефолту) всё равно получается быстрее, чем перебор массива влезающего в кеш целиком.
@@tandemwarhead как я понял, собеседующий имел в виду то, что в некоторых случаях, путем перебора мы можем найти нужное значение быстрее в слайсе, чем по мапе, несмотря на то, что ассимптоматическая сложность нахождения элемента в массиве(слайсе) равна O(N), а в мапе O(1). Но если речь шла про скорость перебора, а не нахождения, то причем тогда здесь кеши проца? Ведь мапа любого размера будет итерироваться дольше из-за указателей, так как при итерации нужно скакать по разным участкам памяти, а не смещаться на константную величину как при итерации по слайсу/массиву. Здесь кеши проца, кмк, не помогут.
Олегу задали вопросы про уровни изоляции и сделали вывод что он там хромает. Странный вывод. Вопрос интервьюерам. А как часто вы меняете дефолтные значения уровней изоляции ? 80% разрабов работающих не в финтехе даже не знает, где это меняется!
Про функцию в defer вопрос скорее всего подразумевал нюанс, что значение аргументов переданные в именованую функцию вычисляются в момент инициализации, а значения аргументов переданные в безымянную функцию с defer берутся в момент сработки defer.
Человек признался, что слушал предыдущее видео, в котором вопросы по Гошке были на 90% такие же - смысл этой части не понятен. Как пошли вопросы по бд(чего не было на прошлом видео) - сразу "поплыл". Вопрос к организпторам: т.к. много топ компаний рф(тиньк, яндекс, авито и тп) активно внедряет подход к собесам из фаанга(а вне РФ - это уже давно стандарт) с отдельным секциям по алгоритмам и систем дизайну, то предоставляете ли вы менторинг по этим направлениям?
потому что нет опыта работы, нужно указывать в резюме и говорить что он типа есть, лайфхак, если вскроется что это не так вас никто не застрелит и не посадит
контракт - довольно широкое применение слова... любой API - это контракт, публичное АПИ какого-то пакета - контракт... схема сообщений, которые прийдут - контракт, даже конфигурация и ее варианты - контракт примите это как "договоренность", описанную или логикой или кодом (типами и интерфейсом) или ожидаемой схемой данных, крч все зависит от контекста обсуждения
Одно из определений термина интерфейс - это контракт между двумя сущностями, одна из которых обладает сигнатурами неких методов. Вторая сущность, соглашаясь на этот контракт - обязывается реализовать все описанные методы. То есть если ты создаешь некую структуру, в которой планируешь имплементировать интерфейс - ты обязан реализовать описанные методы в интерфейсе. В контексте этого интервью контракт = интерфейс.
если честно, system design у парня на нуле, по го - ну такое себе, джун. жаль CAP-теорему не тронули. По поводу master-slave - тут больше балансировщик с кворумом, а вот кэширующий прокси - это новый слой, который по логике, тоже должен быть в кластере, т.е. проблему репликации просто закрыли кэшом!?!?!?!?!? так давайте все писать в кэш + в очередь на запись в БД. Stiky-balancer + master-slave + cache (persistent) + CQRS и кворум
Спасибо большое. Очень полезный контент. На русском лайвинтервью по го почти не было.
> а если мы построим мультимастер репликацию?
> ну тогда можно аутсорснуть кому-нибудь эту историю...
спасибо за поднятое настроение)
37:54
Полный перебор по слайсу всегда быстрее полного перебора по map, а не в каких-то специальных случаях. Даже без всяких кешей процессора, там же обвязка с рандомизацией. Если бы вопрос был наоборот - бывает ли перебор по слайсу быстрее доступа по ключу к map - и тут уже действительно ответ да в особых случаях, на map меньше 8.
большое спасибо за видео , уверен многим это будут на пользу !
Есть не большое но ) Уже не в первый раз слышу от Вас про кеш , тут многие ребята не с большим опытом - не хотелось бы искажать их представление о кеше в рамках систем дизайна
1) в большинстве случаев кеш это костыль , его надо применять очень осознано
2) в топку субд у которой реплики разъезжаются с мастером (ладно если пару раз все бывает и это можно устранить с помощью тулинга бд)
3)исходя из первого то костыль породит еще и синхронизацию которую надо будет реализовать
валидацию, инвалидацию , нехватка памяти и.т.д Породит целую инфраструктуру которую надо поддерживать со своими отдельными проблемам )
Хорошо взвешенный выбор субд+архитектура избавит от кеша или очень сильно его минимизирует .
А еще не совсем понятно от куда у большинства опыт в высоконагруженных проектах ?) у нас типа их пруд пруди ?)
+1
Тоже было очень странно услышать про кэш в рамках такого вопроса. Вообще думал поднимуть вопрос САР теоремы а тут как будто кэш все проблемы решит. Так то тоже не ракрыт вопрос как инвалидировать кэш после обновления БД и какие механизмы для этого использовать. Т.е. от той самой проблемы задержки между обновлением и репликацией/инвалидацией мы никуда не ушли, только заменили одну на другую...
Кэшировать то как раз таки лучше те данные которые редко меняются. Еще не разу не видел чтобы транзакционные данные хорошо поддавались хэшированию.
Отличный проект, ребят! Обязательно к вам приду! Начал учить Go.
как успехи спустя 2 года?
Найс контент) Спасибо 👍🏼
14:07
Интересно.
Побенчмаркал, создал массив строк на 1000 элементов и мапу со строковыми ключами на 1000 элементов.
Искомую строку поставил самым последним элементом массива (чтобы массив целиком прогонялся от первого до последнего элемента при поиске)
Результаты:
Поиск ключа в мапе: ~7ns/op. Поиск элемента в массиве перебором: ~700ns/op. Разница в 100 раз в пользу мапы.
Думал, может с интами будет быстрее, создал мапу с интовыми ключами (в качестве значений struct{}{}) и массив с элементами типа int.
Та же история, мапа ищет в ~100 раз быстрее.
Сократил количество элементов до 100 (и в массиве и в мапе). Мапа перформит всё равно быстрее, раз в 50.
Возможно массив на 5-10 элементов будет пробегаться быстрее мапы, не тестил, но и это вряд ли.
Процессор i7 на MacbookPro.
Да, массив влазит в кеш целиком и на каждой итерации происходит не обращение к памяти, а внутри кеша. Но, видимо, мапы в go оптимизированы так, что прогулка по поинтеру (на бакет) + прогулка по самому бакету (max 8 элементов по дефолту) всё равно получается быстрее, чем перебор массива влезающего в кеш целиком.
go 1.17
10000 элементов
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkSlice-12 469772 2556 ns/op
BenchmarkMap-12 128344011 9.663 ns/op
1000 элементов
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkSlice-12 4334937 274.6 ns/op
BenchmarkMap-12 126898712 9.375 ns/op
100 элементов
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkSlice-12 24449779 42.83 ns/op
BenchmarkMap-12 128677920 9.306 ns/op
10 элементов
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkSlice-12 238751803 4.912 ns/op
BenchmarkMap-12 129417805 9.301 ns/op
1 элемент
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkSlice-12 467830162 2.534 ns/op
BenchmarkMap-12 164359431 7.316 ns/op
Но речь шла про перебор, а не про поиск?
@@tandemwarhead как я понял, собеседующий имел в виду то, что в некоторых случаях, путем перебора мы можем найти нужное значение быстрее в слайсе, чем по мапе, несмотря на то, что ассимптоматическая сложность нахождения элемента в массиве(слайсе) равна O(N), а в мапе O(1).
Но если речь шла про скорость перебора, а не нахождения, то причем тогда здесь кеши проца? Ведь мапа любого размера будет итерироваться дольше из-за указателей, так как при итерации нужно скакать по разным участкам памяти, а не смещаться на константную величину как при итерации по слайсу/массиву. Здесь кеши проца, кмк, не помогут.
@@wskeal86 чтобы задействовать кэш нужно было в массиве элемент искать не один раз, а несколько раз, и потом уже смотреть что будет по скоростям
@@souichimoon во время бенчмаркинга и так это происходит (несколько, точнее много раз).
Спасибо, пойду учить цитаты разрабов про закрытые каналы и другие аспекты языка.
Олегу задали вопросы про уровни изоляции и сделали вывод что он там хромает. Странный вывод.
Вопрос интервьюерам. А как часто вы меняете дефолтные значения уровней изоляции ? 80% разрабов работающих не в финтехе даже не знает, где это меняется!
Ну вывод то правильный. То что это нахрен не надо - это второй вопрос.
Про функцию в defer вопрос скорее всего подразумевал нюанс, что значение аргументов переданные в именованую функцию вычисляются в момент инициализации, а значения аргументов переданные в безымянную функцию с defer берутся в момент сработки defer.
В анонимной функции defer работает точно так же, как и не в анонимной
Можете объяснить что такое выравнивание памяти простым языком?
Спасибо за выпуск.
Durability это долговечность, надежность это reliability.
Ключем к map может быть итерируемый массив. Критерий это сравнимость типа данных ==
Человек признался, что слушал предыдущее видео, в котором вопросы по Гошке были на 90% такие же - смысл этой части не понятен. Как пошли вопросы по бд(чего не было на прошлом видео) - сразу "поплыл".
Вопрос к организпторам:
т.к. много топ компаний рф(тиньк, яндекс, авито и тп) активно внедряет подход к собесам из фаанга(а вне РФ - это уже давно стандарт) с отдельным секциям по алгоритмам и систем дизайну, то предоставляете ли вы менторинг по этим направлениям?
Да, мы пытаемся охватить не только Go, но и алгоритмы и System Design
сидишь такой.. на всё отвечаешь без проблем и с допами.. а тебя даже на джуна не берут потому что резюме не то) Как я рад жить в этом мире)
потому что нет опыта работы, нужно указывать в резюме и говорить что он типа есть, лайфхак, если вскроется что это не так вас никто не застрелит и не посадит
@@souichimoon а как доказать, что он есть?)
@@ibragimov-s3y для этого есть собеседование и испытательный срок
А проэкты на гите есть?
@@OliaYarukhina ))) за 9 месяцев я уже в мидлах )) так что всё хорошо, спасибо)
Разве компилятор не перераспределяет поля, чтобы оптимизировать хранение в памяти, в плюсах современных точно распределяет, верю что в го тоже
Не нашел менторинг для начинающих в телеге, там просто бот
Подскажите, пожалуйста, что за рыба такая «контракт», впервые слышу)
по сути это то из чего состоит запрос и ответ в ручке API
Это метафору такую они использовали
контракт - довольно широкое применение слова... любой API - это контракт, публичное АПИ какого-то пакета - контракт... схема сообщений, которые прийдут - контракт, даже конфигурация и ее варианты - контракт
примите это как "договоренность", описанную или логикой или кодом (типами и интерфейсом) или ожидаемой схемой данных, крч все зависит от контекста обсуждения
Одно из определений термина интерфейс - это контракт между двумя сущностями, одна из которых обладает сигнатурами неких методов. Вторая сущность, соглашаясь на этот контракт - обязывается реализовать все описанные методы. То есть если ты создаешь некую структуру, в которой планируешь имплементировать интерфейс - ты обязан реализовать описанные методы в интерфейсе. В контексте этого интервью контракт = интерфейс.
@@evgeniysergeev9701 вопрос про слово "контракт" а не интерфейс :)
Ух,оказалось за это надо платить(
В бд они оба походу плавают :)
Кажется работодатель сам не знает, зачем у select нужен default. Или просто не раскрывает карты, а соглашается с кандидатом :)
да, согласие или умалчивание помогают не нервировать кандидата, при этом одновременно делает злую шутку с кандидатом и зрителями
Хотелось бы в видео чтобы было меньше грубых слов, все же разработчики, а то "чуваки, фиговый, кореша, мутим" и т д
Кореш, ты че епта, расслабь свой кэш!
Какой нежный
если честно, system design у парня на нуле, по го - ну такое себе, джун. жаль CAP-теорему не тронули. По поводу master-slave - тут больше балансировщик с кворумом, а вот кэширующий прокси - это новый слой, который по логике, тоже должен быть в кластере, т.е. проблему репликации просто закрыли кэшом!?!?!?!?!? так давайте все писать в кэш + в очередь на запись в БД.
Stiky-balancer + master-slave + cache (persistent) + CQRS и кворум
Да нахуй ещё Брюера трогать. А то на собесе спрашивают нюансы и эдж кейсы, а работа: перекладывание джсончиков.
Уйти с C# на го, это как конфетку на дерево обменять, ну такое...
Сишарп говно.