Чайный гриб, мило называющийся scoby по-английски, — это бесконечный источник вкусного газированного напитка, который к тому же ещё и полезен для здоровья. Комбуча может обладать около бесконечной вариативностью вкуса, благодаря возможности добавления любых натуральных ингредиентов на этапе первичного или вторичного брожения (1F, 2F соответственно). Медузомицет очень быстро растёт и не требует многого: всего-то банки, марли и обычного сахара. Его можно выращивать на черном чае, на каркаде, на зеленом чае — даже на кофе и соках.
Почему ВЫ ещё не вкатились в комбучирование?
Почему ВЫ ещё не вкатились в комбучирование?
❤3
Forwarded from Дионисийская мистерия🍇🍷🥴 (𝔐𝔢𝔯𝔠𝔲𝔯𝔶 𝔎𝔞𝔦🌚)
This media is not supported in your browser
VIEW IN TELEGRAM
🍓6❤1❤🔥1
Forwarded from gavr_sas
пезда
мне было сегодня йерс олд когда я узнал что выравнивание динамическое и является буквально самым жирным полем структуры
я знал про дырки и все такое но имел вагуе представление что выравнивание статично и оно тупа по 8(зависит от проца), и что тип чтоб прочитать чтото меньше 8 бит процу просто надо напрягаться на отдельные более долгие операции, поэтому не выгодно ставить поля 4|8|4 нада 4|4|8
ннно, оказывается все куда сложнее хитрее,
есть 2 понятия алайнмента, алайнмент структуры и алайнмент каждого поля
вот в чем выражается алайнмент структуры
есть u32 u32 u64 bool
1111|1111|11111111|1000000
вот, алайнмент всей структуры 8, изза чего после була остается дыра, и он не всегда 8, а в зависимости от самого большого поля, тут u64
а правила алайнмента полей просто:
если поле весит 4 то и начинаться оно должно с адреса кратного 4 если 8 то с адреса кратного 8
то есть 3 була и u32 создадут перед u32 понятную дырку, изза того что именно u32 должен быть размещен по адресу кратному 4
1|1|1|0|1111
мне было сегодня йерс олд когда я узнал что выравнивание динамическое и является буквально самым жирным полем структуры
я знал про дырки и все такое но имел вагуе представление что выравнивание статично и оно тупа по 8(зависит от проца), и что тип чтоб прочитать чтото меньше 8 бит процу просто надо напрягаться на отдельные более долгие операции, поэтому не выгодно ставить поля 4|8|4 нада 4|4|8
ннно, оказывается все куда сложнее хитрее,
есть 2 понятия алайнмента, алайнмент структуры и алайнмент каждого поля
вот в чем выражается алайнмент структуры
есть u32 u32 u64 bool
1111|1111|11111111|1000000
вот, алайнмент всей структуры 8, изза чего после була остается дыра, и он не всегда 8, а в зависимости от самого большого поля, тут u64
а правила алайнмента полей просто:
если поле весит 4 то и начинаться оно должно с адреса кратного 4 если 8 то с адреса кратного 8
то есть 3 була и u32 создадут перед u32 понятную дырку, изза того что именно u32 должен быть размещен по адресу кратному 4
1|1|1|0|1111
👏2
Forwarded from gavr_sas
так, ну и так как я человек JVM не могу не добавить про то насколько она ахуенна, и насколько нейтив черепахи плетуться пожимая крохи комп тайм оптимизаций
—————
в 64битной системе конеш крута шо можно адресовать более 4рех гигов оперативки, нннно и каждый указатель весит в 2 раза больше
struct {
a: *A // 32 на 32, 64 на 64
b: u32
}
хуяк, на 32битной выравнивание всей структуры будет 32, а на 64 64, то есть при наличии одного указателя еще и теоретические дырки становятся больше, больше нагрузка на гц, сплошные минусы, вооот бы был способ иметь 32битные указатели но одновременно аллоцировать более 4рех гигов
————
первое, ЖВМ умеет СЖВМать ссылки!!!
каждая 64битная ссыль выглядит так
пока соблюдено условие что все объекты поместятся ниже адреса 2^32(4 гб),
у нас есть гарантия что первые 32 бита каждого указателя будут нулями, значит их можно нахаляву выбрасывать!
получается пока весим меньше 4 гигов можем жить в мире 32битного адресного пространства, все весит в 2 раза меньше => помещается в кеши, ниже гц нагрузка и ваще радуга
————
но 4ГБ маловато, поэтому все еще хитрее
JVM выравнивает все объекты по 8 БАЙТ
0 = 000000
8 = 001000
16 = 010000
24 = 011000
Как видно 3 последних значения всегда нули(потому что 8 это 1000), так что делаем ещщщё более сумашедшую оптимизацию
че такое 3 бита, 2*2*2 8 значений,
значит у нас есть 8 халявных значений в каждой ссылке,
берем и засовываем туда то на каком из 8ми промежутков по 4 гига мы находимся!!"!"!"№!"💪🏿🤓🌶
(8*4 32)
теперь имеем 32битные указатели
но без минусов 32битного адресного пространства в 4 гига
32 гигов то хватит всем и каждому
—————
в 64битной системе конеш крута шо можно адресовать более 4рех гигов оперативки, нннно и каждый указатель весит в 2 раза больше
struct {
a: *A // 32 на 32, 64 на 64
b: u32
}
хуяк, на 32битной выравнивание всей структуры будет 32, а на 64 64, то есть при наличии одного указателя еще и теоретические дырки становятся больше, больше нагрузка на гц, сплошные минусы, вооот бы был способ иметь 32битные указатели но одновременно аллоцировать более 4рех гигов
————
первое, ЖВМ умеет СЖВМать ссылки!!!
каждая 64битная ссыль выглядит так
0x00000000|12345678пока соблюдено условие что все объекты поместятся ниже адреса 2^32(4 гб),
у нас есть гарантия что первые 32 бита каждого указателя будут нулями, значит их можно нахаляву выбрасывать!
получается пока весим меньше 4 гигов можем жить в мире 32битного адресного пространства, все весит в 2 раза меньше => помещается в кеши, ниже гц нагрузка и ваще радуга
————
но 4ГБ маловато, поэтому все еще хитрее
JVM выравнивает все объекты по 8 БАЙТ
0 = 000000
8 = 001000
16 = 010000
24 = 011000
Как видно 3 последних значения всегда нули(потому что 8 это 1000), так что делаем ещщщё более сумашедшую оптимизацию
че такое 3 бита, 2*2*2 8 значений,
значит у нас есть 8 халявных значений в каждой ссылке,
берем и засовываем туда то на каком из 8ми промежутков по 4 гига мы находимся!!"!"!"№!"💪🏿🤓🌶
(8*4 32)
теперь имеем 32битные указатели
но без минусов 32битного адресного пространства в 4 гига
32 гигов то хватит всем и каждому
Forwarded from gavr_sas
https://t.me/gavr_sas/4279
каждый объект имеет хедер который хранит метаинфу про то какого он типа, лок, и гц бит
8 байт mark word
4 байта compressed class pointer
изза выравнивания получаем еще дырку в 4 байта
———
Project Lilliput
сжимаем этот указатель предыдущим методом, теперь каждый хедер весит 8 байт вместо 16 (JEP 450)
это просто разъеб, и минус дырки и минус оперативка, L кеши в ахуе,
пока не включено по дефолту
-XX:+UnlockExperimentalVMOptions \
-XX:+UseCompactObjectHeaders
каждый объект имеет хедер который хранит метаинфу про то какого он типа, лок, и гц бит
8 байт mark word
4 байта compressed class pointer
изза выравнивания получаем еще дырку в 4 байта
———
Project Lilliput
сжимаем этот указатель предыдущим методом, теперь каждый хедер весит 8 байт вместо 16 (JEP 450)
class Point {
int x;
int y;
}
8 mark word
4 klass pointer
4 x
4 y
4 padding
—>
8 compact header
4 x
4 yэто просто разъеб, и минус дырки и минус оперативка, L кеши в ахуе,
пока не включено по дефолту
-XX:+UnlockExperimentalVMOptions \
-XX:+UseCompactObjectHeaders