👾Мой канал в Telegram: t.me/ntuzov Пишу там новости, анонсы своих активностей и просто интересные мысли Также с его помощью я получаю от вас оперативный фидбэк по роликам - что нравится, что не нравится, какой ролик делать следующим и т.п. ❤ Если у вас есть желание поддержать развитие канала: Секретный телеграм-канал: - В рублях: t.me/+1UPXV_DGnG1mODJi - В евро: t.me/+hedI8LevYTc5MDM6 boosty.to/nikolay.tuzov www.patreon.com/tuzov
Самое крутое в ролике, что какие-то моменты ты проговорил один раз, но потом прошелся по моменту ещё раз, чтобы подробней объяснить тяжелые вещи, спасибо!
Спасибо огромное за такое подробное и подкрепленное исходным кодом объяснение! :) Ждем видео о том, как устроены типы данных в Go! :) Это будет просто пушка :)
Спасибо большое за все эти уроки по ГО. Я очень люблю Low-Level понимание процессов и на каждом видео получил необычайное удовольствие. Этот материал как раз тот, которого мне не хватало чтобы начать работать с ГО. (я не новичок и мне просто не хватало хорошего материала которые разъясняет все эти нюансы)
Объяснение великолепное, канал - супер. Очень хотелось бы увидеть в вашем исполнении разбор интерфейсов, а именно их внутренне устройство, что "под капотом" и как работает
Что хочется поставить во главу угла, так это слова - Ролик отличный! Я смотрел его после видео про мапы с GopherCona 2016 года + прочтения пары небольших статей на эту тему) Мне казалось, что я уже смаплен на знания мап, и, по-началу ролика так и было, вы, мистер Старший разработчик категории 2, уточняли и чуть дополняли те моменты, что я выудил из GopherCon-a, и я уже было думал такой, что сейчас напишу - неплохойперезаливпереводролика2016годасгоферконамэн! Но в один момент я начал понимать, что просто начинаю понимать, а до этого я лишь думал, что я понимаю. Всё настолько просто и последовательно, с таким желанием, с подготовленной последовательной структурой, с желанием научить и быть полезным - прям топовый топ! Спасибо, Николай - это было отличные и очень полезные 34 минуты и 32 секунды! Даже для того, кому казалось, что он уже что-то понимает!) Ждём шедулер!)
Да. Да. Прям бросается в глаза. Но тут можно наверное притянуться за уши то что это опять поотравномерность, и что все элементы не попадут в один бакет.
Спасибо за информацию, завтра попробую под справочник (map) выделить сразу 3000 элементов. Одна из моих программ анализирует Excel-файлы, и на их основе заполняет map. Зачастую в map попадает более 1000 и даже 2000 значений. В моей map содержится справочник работников одного из подразделений с ключом по табельному номеру. Если получится добиться повышения производительности - буду думать над другим проектом, где ключами является совокупность идентификаторов (3), а сама система работает со всеми работниками всех подразделений, которых может более 10 тысяч (работников, конечно).
Николай, на 15:20 вы сказали, что планируете отдельный ролик про внутреннее устройство типов данных в Go. Было бы очень интересно посмотреть видео на эту тему. Большое спасибо за контент)
Конкурентная работа с мапой - неплохая тема для отдельного ролика. Не хотелось затягивать, и так на пол часа вышло =) Но одну важну деталь я дейстивтельно забыл упомянуть - с мапой можно выполнять параллельные читающие операции, поскольку эвакуация данных не происходит во время поиска значения.
3:58 Даже если hash-функция будет очень медленной, то от этого мапа работать за константное время не перестанет. O-нотация не задает ограничения на время работы опереции. Можно придумать примеры, когда алгоритм работающий за линейное время будет работать быстрее, чем другой алгоритм работающий за константное время. Естественно не на большом количестве данных, но все же.
@@nikolay_tuzov подскажите с чего начать изучение если в целом общее представления о всех понятиях в go имею, но ролики Ваши про хэш таблицы и мэпы как на китайском для меня пока что даже 5% не понятно из того что говорите, go это первый язык с которым я столкнулся , прочитал пока пару книг и пытаюсь практиковаться повторяя за обучающими роликами ..
@@alexfederov7772 Во-первых, я бы не советовал начинать с Го. На мой взгляд, лучше начать с Python. Он и проще, и область применения намного шире. Но это субъективно, тут решай сам, сравнивай разные мнения. Во-вторых, я бы посоветовал много практиковаться, и писать самому. В плане алгоритмов, на первых порах можно ограничиться замечательной книгой "грокаем алгоритмы". Она написана супер простым и понятным языком, быстро освоишь основы. Самое главное - не переживай на счет того, что многое по началу непонятно. Так всегда и у всех. Со временем все само в голове уложится, если на это тратить время и практиковаться. Ну и заглядывай в мои телеграм каналы и чатик, я частенько там делюсь советами и т.п. (ссылки есть в описании видео)
Небольшое замечание - alignment делается не для экономии памяти, а для быстродействия. На большинстве современных процессоров доступ к сложным (более одного байта) значениям в памяти будет быстрее, если расположить эти данные по "круглым" адресам
Правильно ли я понимаю, что в массиве бакетов хранятся не указатели на бакеты, а сами бакеты, и именно поэтому нам нужно вычислять сдвиг с помощью битовой маски, как указано на 19:37? В источниках часто говорится что в массиве хранятся указатели на бакеты
Всё зависит от целей разработчиков языка, чему они отдают приоритет - памяти, скорости, каким-то фичам вроде фиксированного порядка и т.п. Это всегда какой-нибудь trade-off
порекомендуйте, пожалуйста, видео по мапам попроще. Я уже разобрался с примитивными типами, ссылками, разыменовыванием слайсами. Но как работают мапы и для чего не могу понять. Мне порекомендовали этот видос. Вижу, что тут крутая структурированная подача, но все равно я еще не на том уровне, чтобы понять это.
Погугли просто про хэш-таблицу. Мапа в го - это просто реализация хэш-таблицы в коде. А хэш-таблица в свою очередь это разновидность ассоциативного массива.
Пересмотрел 2 раза, и ещё пол раза по непонятным моментам. Остались непонятными три вещи: - HOB хранятся в массиве структуры бакета, или это восемь разных полей в структуры бакета? - Что произойдёт, если эвакуация не завершена, а лоад фактор для новых бакетов равен 6.5? Мы создаём опять новую область памяти и будем смотреть Бакеты уже в трёх картах?
Выходит, если HOB запрошенного ключа соответствует какому-либо HOB в бакете, то мы переходим к соответствующему ключу в бакете и сравниваем его с запрошенным. Если они не равны, сравниваем HOBы дальше
Спасибо за видео, очень доступно. Возникает вопрос, если мы создаем мапу make(map[string]int, 10) можем ли мы быть уверены что положив туда 10 элементов точно не произойдет выделения доп памяти и эвакуации данных? По идеи не можем, ведь возможны коллизии и теоретически все эти 10 элементов могут указывать на 1 бакет. Поэтому не очень понятно что именно происходит когда указываем конкретный размер мапы в make()?
28:35 Николай: мы можем указать размер мапы, таким образом, ЭВАКУАЦИИ ДАННЫХ НЕ ПРОИЗОЙДЕТ 29:13 Также Николай: мы не можем взять указатель, потому что в какой-то момент ПРОИЗОЙДЕТ ЭВАКУАЦИЯ ДАННЫХ 😂😂
Очевидно, что эвакуация не произойдёт, если мы добавим ровно столко элементов, сколько запланировали, не больше. Но компилятор наши намерения не знает, эвакуация всегда должна быть возможна, поэтому указатель взять нельзя.
@@nikolay_tuzov да, я это понимаю, но неужели компилятор и рантайм го настолько глупый? условно, там же есть оптимизации, когда слайс растет х2, потом х1.25, неужели с эвакуацией мапы нет ничего такого?
Например, для мапы с постоянным размером отдельный тип const size map под капотом, который позволяет брать указатели Как для массива есть тип отдельный, а для непостоянного слайса другой тип (array с заданным размером и slice - разные типы в го)
А можно, пожалуйста, еще раз объяснить, почему на мапу должны выделять память через make? я понимаю, что иначе будет nil, но что такого в устройстве ее особенного? или можно таймкод скинуть, где я это упустил
Хотел задать вопрос один, насчет эвакуацией данных. Когда слайс из бакетов заполняется, и надо новую память аллоцировать для списка бакетов, го также, вдвое больше берет памяти или по какому то другому алгоритму увеличивает память?
Там не совсем в два раза увеличение происходит при эвакуации бакетов. Там вроде как специальная формула есть, которая меняется в зависимости от текущего размера
у меня вчера мапа вывелась один раз не оп очереди вставленных элементов, а потом да еще 10 разу отсортировано.)) так и не смог поймать еще раз тоже состояние что было изначально показано. скорее всего игра кеша ибо через run запускал а не билдил.))
Спасибо за видео. Но для меня некоторые места остались темными. 1. когда вычисляется lob то количество бит равно логарифму от количества бакетов. А если количество бакетов не равно степени двойки, то не будет однозначного соответствия между бакетами и значениями lob. Нет ли такого, что внутри поддерживается что количество бакетов всегда равно степени двойки, и если мы делаем make(m[int]int, 1000) то бакетов будет 1024? 2. Не очень понятно как происходит эвакуация. Допустим коэффициент заполнения стал больше 6.5 мы алоцировали новую мапу с количеством бакетов в два раза большим. Теперь у нас есть операции получения, удаления, вставки (которая может быть просто перезаписью) и итерации по мепе. окей, если это не итерация, то можно сходит в две мепы и сделать все что нужно. Потом после нескольких таких операций происходит итерация по мепе, и вот тут вообще не понятно что происходит. часть данных эвакуировалось, а часть нет, но также у нас могли быть новые значения, которые нет в старой мепе.
извиняюсь туплю. а где непосредственно решается коллизия? был рассмотрен поиск по ключу. а что происходит при вставке в мапу если получили один и тот же хеш. старшие биты ведь одинаковые.
Ну, когда вставляем ключ, коллизирующий с уже имеющимся ключом в мапе, будет так: - по lob нового ключа найдём его бакет - в этом бакете по списку его hob'ов проверим, что в нём вероятно уже есть наш новый ключ - пробежимся по ключам в бакете и не найдём точного совпадения с новым ключом, поэтому вставим этот ключ в него. При этом в список hob'ов этого бакета нет смысла второй раз вставлять одинаковый hob
@@buginsystem8925 а как именно вставляем? там показано что это массив. тоесть мы вставляем в конец? и получается как мы тогда читаем по ключу. заходим все так же в бакет находим по старшим первый элемент проверяем что там не тот ключ И? перебираем оставшийся массив? спасибо за ответ)
Такой вот вопрос: Действительно ли нельзя взять адрес элемента мапы из-за миграции? В слайсе у нас тоже происходит перевыделение памяти, и там мы можем взять адрес, хоть он так же может потерять свою актуальность.
Эвакуация данных не делает процедуру взятия указателя принципиально невозможной. Просто реализация становится очень сложной. Слайс, всё же, намного проще мапы - там внутри простой массив, а не сложная структура бакетов. Да и процесс копирования данных у слайса происходит сразу, а не постепенно. Но вполне возможно, что я что-то ещё упускаю.
непонятно насчёт того, почему нельзя брать ссылку на значение в мапе. понятно, что данные переносятся, но ведь в слайсе при len == cap данные тоже уходят в другое место? почему там можно
Привет. Подскажи, асимптотическая сложность вставки в мапу это 10? А удаления? Получение получается 01? Можешь объяснить в кратце этот момент? Честно не понимаю к чему такие сложности, ну принцип работы мапы ясен, задаёшь размер памяти изначально, для чего все эти углубления, про асимптотику и тп непонятно для меня))) Функции же уже определены под капотом, как на них влиять в процессе, помимо ограничений в памяти?
Это довольно простая тема, но в комментариях всё равно сложно объяснить. Крайне рекомендую почитать книгу "Грокаем алгоритмы" - она довольно маленькая и написана очень понятным языком. Уверяю, после неё подобных вопросов не останется.
но ведь если у нас увеличивается количество элементов в мапе, увеличивается и количество бакетов, а бакеты мы тоже должны же как-то находить? если перебором, то время выполнения тем больше, чем больше кол-во бакетов
go смердит как старый добрый с, то количество ограничений, которое в него вколотили создатели ( видимо в угоди скорости компиляции ) полностью отбивает какое либо желание с ним работать. Видео хорошее, на мой взгляд немного перегружено кишочками и наверное будет неудобо варимо для начинающих.
@@nikolay_tuzov а ты типы данные хорошо знаешь? Какие типы данных из компьютерных наук соответствуют типу map? Там есть подходящие, кали тебе не нравится слово карта. Да и можно «карты», в английском это слово ровно это значит и никого не стремает это. Только наших застенчивых и закомплексованных кодеров смущает прямое значение слов.
@@nikolay_tuzov ага, хомяки именно так говорят и потом плавают в сутевой части, несопосбные объяснить почему слайсы это именно слайсы и мапы. Как попугайчики выучившие красивые слова)) Используемые термины - показатель квалификации и умение думать, а не повторять.
👾Мой канал в Telegram: t.me/ntuzov
Пишу там новости, анонсы своих активностей и просто интересные мысли
Также с его помощью я получаю от вас оперативный фидбэк по роликам - что нравится, что не нравится, какой ролик делать следующим и т.п.
❤ Если у вас есть желание поддержать развитие канала:
Секретный телеграм-канал:
- В рублях: t.me/+1UPXV_DGnG1mODJi
- В евро: t.me/+hedI8LevYTc5MDM6
boosty.to/nikolay.tuzov
www.patreon.com/tuzov
В самое сердце! Продолжай нести добро в этот мир!
Самое крутое в ролике, что какие-то моменты ты проговорил один раз, но потом прошелся по моменту ещё раз, чтобы подробней объяснить тяжелые вещи, спасибо!
Это лучшее видео о внутренней кухне языка которое я видела. Бесконечная благодарность 💔💐
Очень нравиться такой подход, а именно углубление в изучение решений разработчиков с разбором. Крайнее полезно, спасибо!
Как же я Вам благодарен! Один из лучших каналов в данном сегменте, спасибо!
Отличный обзор, Николай. Все разобрано по кирпичикам, очень легко и доступно воспринимается довольно таки сложная тема. Безграничный респект!
Спасибо огромное за такое подробное и подкрепленное исходным кодом объяснение! :) Ждем видео о том, как устроены типы данных в Go! :) Это будет просто пушка :)
Друг ты реально топ))), вот это мужик!!! Спасибо за старания!!!
Спасибо большое за все эти уроки по ГО. Я очень люблю Low-Level понимание процессов и на каждом видео получил необычайное удовольствие.
Этот материал как раз тот, которого мне не хватало чтобы начать работать с ГО. (я не новичок и мне просто не хватало хорошего материала которые разъясняет все эти нюансы)
Да уж, спасибо тебе за труд в подготовке таких качественных материалов!
Чел, ты жётский, спасибо большое, очень грамотно объясняешь
Спасибо, отличное видео, хорошо освежает знания в памяти, ждем видео про устройство типов в го!
Объяснение великолепное, канал - супер. Очень хотелось бы увидеть в вашем исполнении разбор интерфейсов, а именно их внутренне устройство, что "под капотом" и как работает
С удовольствием расскажу об этом, такая тема уже есть в планах 😊
@@nikolay_tuzov очень жду!)
Уже который раз пересматриваю видео для того чтобы освежить в памяти. Классика )
Огромное спасибо автору за подробный разбор темы!!!!!!!!!! То что надо!
Спасибо за труд. Хорошо объясняешь. Ждем продолжения
Что хочется поставить во главу угла, так это слова - Ролик отличный!
Я смотрел его после видео про мапы с GopherCona 2016 года + прочтения пары небольших статей на эту тему)
Мне казалось, что я уже смаплен на знания мап, и, по-началу ролика так и было, вы, мистер Старший разработчик категории 2, уточняли и чуть дополняли те моменты, что я выудил из GopherCon-a, и я уже было думал такой, что сейчас напишу - неплохойперезаливпереводролика2016годасгоферконамэн!
Но в один момент я начал понимать, что просто начинаю понимать, а до этого я лишь думал, что я понимаю. Всё настолько просто и последовательно, с таким желанием, с подготовленной последовательной структурой, с желанием научить и быть полезным - прям топовый топ!
Спасибо, Николай - это было отличные и очень полезные 34 минуты и 32 секунды! Даже для того, кому казалось, что он уже что-то понимает!)
Ждём шедулер!)
о класс..сейчас чайка налью... и смотреть))).Всем приятного!!!🎉
Спасибо! Теперь я знаю как устроен тип map!
Лучшее лекция по ИТ что я видел за долгое время
В структуре map-ы никакая криптостойкость от хэш функции не требуется, не нужно путать хэш функции используемые для криптографии и для шардирования.
Да. Да. Прям бросается в глаза.
Но тут можно наверное притянуться за уши то что это опять поотравномерность, и что все элементы не попадут в один бакет.
0:20 наконец-то узнал, куда ставить ударение в фамилии ))
Антоха МС решил не останавливаться на построении муз карьере и решил строить карьеру в IT на гошке. Лайк этому трудяге
Очень круто, спасибо! Отдельное спасибо за разбор исходного кода Go
Спасибо за информацию, завтра попробую под справочник (map) выделить сразу 3000 элементов. Одна из моих программ анализирует Excel-файлы, и на их основе заполняет map. Зачастую в map попадает более 1000 и даже 2000 значений. В моей map содержится справочник работников одного из подразделений с ключом по табельному номеру.
Если получится добиться повышения производительности - буду думать над другим проектом, где ключами является совокупность идентификаторов (3), а сама система работает со всеми работниками всех подразделений, которых может более 10 тысяч (работников, конечно).
Спасибо за ваш труд! Намного понятнее стал принцип работы с бакетами внутри map :)
Отличный канал бро, уже на третьем видео залипаю
Да это просто клад!
Николай, на 15:20 вы сказали, что планируете отдельный ролик про внутреннее устройство типов данных в Go. Было бы очень интересно посмотреть видео на эту тему. Большое спасибо за контент)
Посмотрел на одном дыхании, хоть я вообще питонист и с го никогда не работал :)
Спасибо большое за ваш труд! Смотрю все ролики с большим удовольствием:)
Николай, спасибо за видео
великолепное видео. спасибо большое. подписался, колокольчик тыкнул)
Лучшее видео про map! Спасибо)
Я очень рад, что нашёл этот канал. Продолжай!
Большое спасибо за Ваш труд! Это самое подробное и понятное описание мап
лайк) стоило еще рассказать про конкурентную работу с мапой и какой фейл там может произойти
Конкурентная работа с мапой - неплохая тема для отдельного ролика. Не хотелось затягивать, и так на пол часа вышло =)
Но одну важну деталь я дейстивтельно забыл упомянуть - с мапой можно выполнять параллельные читающие операции, поскольку эвакуация данных не происходит во время поиска значения.
3:58 Даже если hash-функция будет очень медленной, то от этого мапа работать за константное время не перестанет. O-нотация не задает ограничения на время работы опереции. Можно придумать примеры, когда алгоритм работающий за линейное время будет работать быстрее, чем другой алгоритм работающий за константное время. Естественно не на большом количестве данных, но все же.
Согласен, вы правы.
Когда я называл медленной функцию с линейным временем, я имел ввиду ассимптотику. Наверное, стоило это уточнить.
@@nikolay_tuzov подскажите с чего начать изучение если в целом общее представления о всех понятиях в go имею, но ролики Ваши про хэш таблицы и мэпы как на китайском для меня пока что даже 5% не понятно из того что говорите, go это первый язык с которым я столкнулся , прочитал пока пару книг и пытаюсь практиковаться повторяя за обучающими роликами ..
@@alexfederov7772 Во-первых, я бы не советовал начинать с Го. На мой взгляд, лучше начать с Python. Он и проще, и область применения намного шире. Но это субъективно, тут решай сам, сравнивай разные мнения.
Во-вторых, я бы посоветовал много практиковаться, и писать самому.
В плане алгоритмов, на первых порах можно ограничиться замечательной книгой "грокаем алгоритмы". Она написана супер простым и понятным языком, быстро освоишь основы.
Самое главное - не переживай на счет того, что многое по началу непонятно. Так всегда и у всех. Со временем все само в голове уложится, если на это тратить время и практиковаться.
Ну и заглядывай в мои телеграм каналы и чатик, я частенько там делюсь советами и т.п. (ссылки есть в описании видео)
@@nikolay_tuzov большое спасибо за развернутый ответ!
Ну мужиик 👍!! Спасибо огромное за видео!
Николай красавец вперед дерзай
Чудесно звучит 🎉 а когда будет продолжение этой темы разговора
А что именно интересует в качестве продолжения?
Очень интересный урок. Спасибо!
Отличное видео! Огромное спасибо автору!
Спасибоз за крутой видос по мапам)
подробное хорошее видео, спасибо
Невероятно. Огромное спасибо!!
хорошее видео. Хотелось бы подобное про интерфейсы
Небольшое замечание - alignment делается не для экономии памяти, а для быстродействия. На большинстве современных процессоров доступ к сложным (более одного байта) значениям в памяти будет быстрее, если расположить эти данные по "круглым" адресам
Спасибо за видео. Коммент в поддержку!
Здравствуйте, Николай. Спасибо за очень классные видео))) Однозначно лайк, подписка, колокольчик)))
Круто. Спасибо!
Спасибо. Познавательно.
Правильно ли я понимаю, что в массиве бакетов хранятся не указатели на бакеты, а сами бакеты, и именно поэтому нам нужно вычислять сдвиг с помощью битовой маски, как указано на 19:37? В источниках часто говорится что в массиве хранятся указатели на бакеты
бакеты бакеты бакеты
ничего не понятно, но очень интересно (с)
Спасибо за отличное объяснение!
Даёшь ролик про подробное устройство типов данных в Go!))
Очень крутое видео!
топ. продолжай, пожалуйста
Спасибо, отличное видео! Планируется ли видео об указателях?
Пока не планируется. Даже не знаю, что о них можно рассказать на целое видео =)
Есть идеи?
@@nikolay_tuzov Прям подробный рассказ со всеми нюансами и тонкостями
Спасибо за лекцию. Как происходит удаление ключа из бакета ? Ключ удаляется или помечается как удаленный?
А про выравнивание типов нет видео еще? Было бы интересно посмотреть
Человечище!
В Kotlin есть LinkedHashMap. Там происходит итерация по элементам в порядке добавления в Map.
Всё зависит от целей разработчиков языка, чему они отдают приоритет - памяти, скорости, каким-то фичам вроде фиксированного порядка и т.п.
Это всегда какой-нибудь trade-off
Лайк поставил. Интересно. GO!!!
Просто лучший! 🙂
сколько байт занимают high order bits? От чего это зависит? Зависит ли это от количества бакетов?
порекомендуйте, пожалуйста, видео по мапам попроще. Я уже разобрался с примитивными типами, ссылками, разыменовыванием слайсами.
Но как работают мапы и для чего не могу понять. Мне порекомендовали этот видос. Вижу, что тут крутая структурированная подача, но все равно я еще не на том уровне, чтобы понять это.
Я тебе скажу одно, проще и понятнее как работает мапа изнутри не найдешь. Именно как в го это устроено
Погугли просто про хэш-таблицу. Мапа в го - это просто реализация хэш-таблицы в коде. А хэш-таблица в свою очередь это разновидность ассоциативного массива.
Спасибо большое!
Пересмотрел 2 раза, и ещё пол раза по непонятным моментам. Остались непонятными три вещи:
- HOB хранятся в массиве структуры бакета, или это восемь разных полей в структуры бакета?
- Что произойдёт, если эвакуация не завершена, а лоад фактор для новых бакетов равен 6.5? Мы создаём опять новую область памяти и будем смотреть Бакеты уже в трёх картах?
Выходит, если HOB запрошенного ключа соответствует какому-либо HOB в бакете, то мы переходим к соответствующему ключу в бакете и сравниваем его с запрошенным. Если они не равны, сравниваем HOBы дальше
Николай, по мимо go есть ли опыт в других языках?
Да, я на разных писал - php, python, java и др. Но если говорить про коммерческие проекты, то в основном php и go
Спасибо за видео, очень доступно.
Возникает вопрос, если мы создаем мапу make(map[string]int, 10) можем ли мы быть уверены что положив туда 10 элементов точно не произойдет выделения доп памяти и эвакуации данных? По идеи не можем, ведь возможны коллизии и теоретически все эти 10 элементов могут указывать на 1 бакет. Поэтому не очень понятно что именно происходит когда указываем конкретный размер мапы в make()?
сложно =) но достаточно интересно
Спасибо большое, я бы тебя украл и дома посадил :))) Все быстро, четко и главное на понятном русском языке.
28:35 Николай: мы можем указать размер мапы, таким образом, ЭВАКУАЦИИ ДАННЫХ НЕ ПРОИЗОЙДЕТ
29:13 Также Николай: мы не можем взять указатель, потому что в какой-то момент ПРОИЗОЙДЕТ ЭВАКУАЦИЯ ДАННЫХ
😂😂
Очевидно, что эвакуация не произойдёт, если мы добавим ровно столко элементов, сколько запланировали, не больше. Но компилятор наши намерения не знает, эвакуация всегда должна быть возможна, поэтому указатель взять нельзя.
@@nikolay_tuzov да, я это понимаю, но неужели компилятор и рантайм го настолько глупый? условно, там же есть оптимизации, когда слайс растет х2, потом х1.25, неужели с эвакуацией мапы нет ничего такого?
Например, для мапы с постоянным размером отдельный тип const size map под капотом, который позволяет брать указатели
Как для массива есть тип отдельный, а для непостоянного слайса другой тип (array с заданным размером и slice - разные типы в го)
А можно, пожалуйста, еще раз объяснить, почему на мапу должны выделять память через make? я понимаю, что иначе будет nil, но что такого в устройстве ее особенного? или можно таймкод скинуть, где я это упустил
Хотел задать вопрос один, насчет эвакуацией данных. Когда слайс из бакетов заполняется, и надо новую память аллоцировать для списка бакетов, го также, вдвое больше берет памяти или по какому то другому алгоритму увеличивает память?
Я об этом говорил в части про бакеты - 27:05
Будет выделено в 2 раза больше бакетов.
@@nikolay_tuzov да, спасибо, я что то упустил видимо этот момент когда писал себе лекцию))) Еще раз, спасибо
Там не совсем в два раза увеличение происходит при эвакуации бакетов. Там вроде как специальная формула есть, которая меняется в зависимости от текущего размера
как и при расширении среза, йес
у меня вчера мапа вывелась один раз не оп очереди вставленных элементов, а потом да еще 10 разу отсортировано.)) так и не смог поймать еще раз тоже состояние что было изначально показано. скорее всего игра кеша ибо через run запускал а не билдил.))
Спасибо за видео. Но для меня некоторые места остались темными.
1. когда вычисляется lob то количество бит равно логарифму от количества бакетов. А если количество бакетов не равно степени двойки, то не будет однозначного соответствия между бакетами и значениями lob. Нет ли такого, что внутри поддерживается что количество бакетов всегда равно степени двойки, и если мы делаем make(m[int]int, 1000) то бакетов будет 1024?
2. Не очень понятно как происходит эвакуация. Допустим коэффициент заполнения стал больше 6.5 мы алоцировали новую мапу с количеством бакетов в два раза большим. Теперь у нас есть операции получения, удаления, вставки (которая может быть просто перезаписью) и итерации по мепе. окей, если это не итерация, то можно сходит в две мепы и сделать все что нужно. Потом после нескольких таких операций происходит итерация по мепе, и вот тут вообще не понятно что происходит. часть данных эвакуировалось, а часть нет, но также у нас могли быть новые значения, которые нет в старой мепе.
извиняюсь туплю. а где непосредственно решается коллизия? был рассмотрен поиск по ключу. а что происходит при вставке в мапу если получили один и тот же хеш. старшие биты ведь одинаковые.
Ну, когда вставляем ключ, коллизирующий с уже имеющимся ключом в мапе, будет так:
- по lob нового ключа найдём его бакет
- в этом бакете по списку его hob'ов проверим, что в нём вероятно уже есть наш новый ключ
- пробежимся по ключам в бакете и не найдём точного совпадения с новым ключом, поэтому вставим этот ключ в него. При этом в список hob'ов этого бакета нет смысла второй раз вставлять одинаковый hob
@@buginsystem8925 а как именно вставляем? там показано что это массив. тоесть мы вставляем в конец? и получается как мы тогда читаем по ключу. заходим все так же в бакет находим по старшим первый элемент проверяем что там не тот ключ И? перебираем оставшийся массив? спасибо за ответ)
Такой вот вопрос: Действительно ли нельзя взять адрес элемента мапы из-за миграции? В слайсе у нас тоже происходит перевыделение памяти, и там мы можем взять адрес, хоть он так же может потерять свою актуальность.
Эвакуация данных не делает процедуру взятия указателя принципиально невозможной. Просто реализация становится очень сложной.
Слайс, всё же, намного проще мапы - там внутри простой массив, а не сложная структура бакетов. Да и процесс копирования данных у слайса происходит сразу, а не постепенно.
Но вполне возможно, что я что-то ещё упускаю.
Вообще, это очень хороший вопрос.
Если в целом тебе подобные темы интересны, заглядывай в наш чатик, будем обсуждать.
t.me/+WyjmnP6la_QyYjAy
Спасибо!
непонятно насчёт того, почему нельзя брать ссылку на значение в мапе. понятно, что данные переносятся, но ведь в слайсе при len == cap данные тоже уходят в другое место? почему там можно
Ты крутой
Думал - чо такое длинное видео, на 34 минуты. Так его еще и на 0.75 пришлось смотреть, чтобы не потерять суть.
Я про старшие и младшие биты хэша немного не понял. Когда используются LOB, а когда HOB?
будет такое же видео об интерфейсах, сборщике мусора, горутинах?
Да, будет
Привет. Подскажи, асимптотическая сложность вставки в мапу это 10? А удаления? Получение получается 01? Можешь объяснить в кратце этот момент? Честно не понимаю к чему такие сложности, ну принцип работы мапы ясен, задаёшь размер памяти изначально, для чего все эти углубления, про асимптотику и тп непонятно для меня)))
Функции же уже определены под капотом, как на них влиять в процессе, помимо ограничений в памяти?
Это довольно простая тема, но в комментариях всё равно сложно объяснить. Крайне рекомендую почитать книгу "Грокаем алгоритмы" - она довольно маленькая и написана очень понятным языком. Уверяю, после неё подобных вопросов не останется.
Получается если алоцировать Мапу с длинной равной 2 у нас в структуре мапы будет один бакет?
Доброго времени суток. Разберите, пожалуйста, структуры и собственные типы данных с указателями
но ведь если у нас увеличивается количество элементов в мапе, увеличивается и количество бакетов, а бакеты мы тоже должны же как-то находить? если перебором, то время выполнения тем больше, чем больше кол-во бакетов
А если у нас нечетное кол-во бакетов какое будет поведение?
Супер!!!
Super!!!
go смердит как старый добрый с, то количество ограничений, которое в него вколотили создатели ( видимо в угоди скорости компиляции ) полностью отбивает какое либо желание с ним работать. Видео хорошее, на мой взгляд немного перегружено кишочками и наверное будет неудобо варимо для начинающих.
Такой херни даже в самом плохом С редко увидишь
Как понять в: бакете лежит 6 с половиной значений?)
ua-cam.com/video/P_SXTUiA-9Y/v-deo.html
Ключевая фраза - "в среднем".
Например, если у тебя 2 бакета, и в одном лежит 7 значений, в другом 6, то среднее значение будет - 6.5:
(7 + 6)/2 = 6.5
eta tochno shto make rabotayet dlya map ?? ya gdeta videl shto gavarili make bespolezniy dlya map
Не слайсы, а срез. Про мэп вообще молчу 😂
Ну да, надо было говорить - карта
Как устроены карты в Go?
@@nikolay_tuzov а ты типы данные хорошо знаешь? Какие типы данных из компьютерных наук соответствуют типу map? Там есть подходящие, кали тебе не нравится слово карта.
Да и можно «карты», в английском это слово ровно это значит и никого не стремает это. Только наших застенчивых и закомплексованных кодеров смущает прямое значение слов.
@@ilyadruzh а зачем что-то выдумывать, если есть уже привычные map и слайс? Они вошли в обиход, и чаще всего говорят / пишут именно так.
@@nikolay_tuzov ага, хомяки именно так говорят и потом плавают в сутевой части, несопосбные объяснить почему слайсы это именно слайсы и мапы. Как попугайчики выучившие красивые слова)) Используемые термины - показатель квалификации и умение думать, а не повторять.