Comments 17
Для уменьшения негативного эффекта достаточно просто поменять местами поля в структуре: так, чтобы маленькие однобайтовые поля были в начале, а большой, четырехбайтный int — в самом конце:
Лучше делать наборот - маленькие в конце, иначе может случиться padding:
Data alignment is the aligning of elements according to their natural alignment. To ensure natural alignment, it may be necessary to insert some padding between structure elements or after the last element of a structure. For example, on a 32-bit machine, a data structure containing a 16-bit value followed by a 32-bit value could have 16 bits of padding between the 16-bit value and the 32-bit value to align the 32-bit value on a 32-bit boundary. Alternatively, one can pack the structure, omitting the padding, which may lead to slower access, but uses three quarters as much memory.
Все было хорошо и понятно, пока не дошли до мап. Стоит немного рассказать, что за эвакуация и зачем она нужна. И в контексте хеш-таблиц насколько вообще общепринят термин эвакуации? Обычно говорят о росте хеш-таблицы и о переносе ее элементов (как раз эвакуации).
И такой вопрос: в go рост таблицы асинхронен? Зачем хранить старый bucket, если рост при вставке элемента происходит синхронно для хеш-таблиц обычно?
Да, согласен, немного не корректно получилось. Наверное, стоило явно писать "эвакуация данных" когда это подразумевалось, а то местами выглядит будто эвакуация мапы.
По росту - да, в go он асинхронный. Из-за этого могут возникать ситуации когда при попытке доступа к данным часть бакетов уже переехала, а часть нет. Но, благодаря этому не происходит просадок во время роста большой мапы.
Но, благодаря этому не происходит просадок во время роста большой мапы.
А если все ядра уже заняты полезной вычислительной работой, разве асинхронная обработка не повлияет на производительность?
Повлияет, конечно. На саму асинхронную обработку, так или иначе, действительно расходуются ресурсы. Но я бы не сказал что это проблема асинхронной обработки, это скорее проблема выбора инструмента и(или) подхода к разработке. Если есть задача в которой необходимо утилизировать 100% CPU, ну, кажется стоит обратить внимание на более низкоуровневые языки. И самостоятельно управлять потоками, памятью и прочим.
Асинхронная обработка в го, скорее (но не только), позволяет, так сказать, выполнять операции которые можно не делать прямо сейчас в отложенном режиме.
Мне как начинающему, хотелось бы реализацию метода util.PrintAsBinary посмотреть, если это возможно?
@stkevich а почему при втором выводе мапы отсутствует добавленный элемент x[5]=2?
Там, на самом деле, отсутствуют и другие элементы. Просто выводится содержимое только одного бакета. А во втором выводе, после роста мапы, бакетов становится уже несколько. Собственно, распределение элементов по бакетам после роста мапы - процесс случайный и просто так получилось что новый элемент попал в новый бакет, который просто не вывели. Если позапускать код несколько раз - то можно поймать его и в этом бакете.
Отличная статья, спасибо
В разделе "Выравнивание структур" опечатка в имени типа
alignmentStruct12 -> alignmentStruct8
А по какой границе была выровнена структура, что вышло 12 байт на структуру ? Машина 32- битная ? Тогда логично по 4 байта одно поле структуры
Потрошим golang: как устроена память