E
оно то понятное дело где-то там наступало на кэшлайн границу и пенальтилось, но в целом на результаты не сказалось.
+ оверхед от ручного выравнивания
+ оверхед от ручного выравнивания
Size: a a a
2020 February 10
IN
Ну и на жирных микроархитектурах типа десктопных интелов этот пенальти может быть смазан дофига умным префетчером и длиииинным окном для спекуляции, да. Но на домашнем роутере, например, это уже не прокатит :)
AS
Nikolay
Зачем в java используется выравние объектов , что бы размер их стал кратен 8 байтам ?
Потому что иначе сложно гарантировать выровненный доступ к содержимому объектов. Для байтов -- не страшно, а вот если есть поле типа volatile long или хедер объекта, то для атомарного доступа к нему, его мало положить на офсет, кратный 8 внутри объекта, надо ещё и сам объект на 8 выровнять.
K
Потому что иначе сложно гарантировать выровненный доступ к содержимому объектов. Для байтов -- не страшно, а вот если есть поле типа volatile long или хедер объекта, то для атомарного доступа к нему, его мало положить на офсет, кратный 8 внутри объекта, надо ещё и сам объект на 8 выровнять.
А зачем сам объект?
K
А, я понял, оффсет-то у поля от начала объекта
N
Вот ту не пойму. Процессор же в память ходит не по 8 байтов , а целую кэш линию загружает , которая вроде 256 байтов ?
E
Nikolay
Вот ту не пойму. Процессор же в память ходит не по 8 байтов , а целую кэш линию загружает , которая вроде 256 байтов ?
64
E
на армах 128
AS
Nikolay
Вот ту не пойму. Процессор же в память ходит не по 8 байтов , а целую кэш линию загружает , которая вроде 256 байтов ?
Ну дак невыровненное поле может лежать двумя ногами на разных кешлайнах, и привет атомарности.
E
кстати, 64байтный кэш я так понимаю делает бессмысленным авх-1024 -_-
AS
кстати, 64байтный кэш я так понимаю делает бессмысленным авх-1024 -_-
Ослабят требования к консистенстности памяти на широкие доступы :) Портов-то побольше запихать, чтобы можно было ещё больше кеш-линий в полёте держать, и всё, готово. Программируйте! 😁
N
64
Понял. Значит ходим в память по 64 байта. А почему объекты выравние не по 64 байта ?
AS
Nikolay
Понял. Значит ходим в память по 64 байта. А почему объекты выравние не по 64 байта ?
Зачем, если хватает выравнивать на 8? Выровняете на 64, будете в 8х больше памяти жрать.
N
Зачем, если хватает выравнивать на 8? Выровняете на 64, будете в 8х больше памяти жрать.
А может ли такое получится ,что long , например попадет на 2 линии ? Например идёт сначала заголовок объекта в 4+4 байта ,а потом 55 байтовых полей , а за ними long?
AT
Зачем, если хватает выравнивать на 8? Выровняете на 64, будете в 8х больше памяти жрать.
Это же виртуальной памяти "жрать", а не физической? 😊
E
Nikolay
А может ли такое получится ,что long , например попадет на 2 линии ? Например идёт сначала заголовок объекта в 4+4 байта ,а потом 55 байтовых полей , а за ними long?
естественно, но структуры обычно паддингами равняют
E
а потом эти паддинги выстреливают тебе в ногу если ты сравниваешь их через memcmp -_-
N
Ну дак невыровненное поле может лежать двумя ногами на разных кешлайнах, и привет атомарности.
Ах. Наверное я понял. Выравниваем мы по размеру long и это не зависит от ширина кэш линии
AS
Nikolay
А может ли такое получится ,что long , например попадет на 2 линии ? Например идёт сначала заголовок объекта в 4+4 байта ,а потом 55 байтовых полей , а за ними long?
long выравняется внутри объекта на 8. Сам объект выравняется тоже на 8. Итого, long будет выравнен на 8.
AS
Это же виртуальной памяти "жрать", а не физической? 😊
Ну... С выравниванием на 64 аллоцировали объект в 8 байт по адресу X. Следующий можно аллоцировать по адресу X+64. Продолбали 56 байт. Это какой памяти продолбали -- виртуальной или физической? Ответ: и той, и другой, потому что страницы куда жирнее ;)