А пока я нахожусь в отрицании, что мой бывший любимый менеджер уходит со словами "I need to find some meaning in what I want to do", что самому хочется задекларировать выгорание банкротство идей. Точь в точь как написано в статье, что я прочитал сегодня на Vox. Это 16-й человек ушедший из команды за 1.5 года и 12-й senior+. Из ~30 человек я 3-й по tenure в одной из самых важных для инфры команд в Google. Мой новый менеджер мне не нравится, фу. Бьёт по морали, поговорил с менторами, и все обожают задавать вопрос: "А что ты хочешь?". Как будто это помогает, но я тоже теперь буду его задавать всем, чтобы выглядеть, что я тоже помогаю :)
Но я что-то интересное узнал про себя за последние 2 недели.
Я верю в свой проект, я верю в Google и Google Cloud. Но вот фактор людей у меня отняли на текущий момент, очень грустно. Ново пришедшие неинтересные какие-то, если честно. Tech Leadership меня вгоняет в тоску, когда мне интересно работать с одним человеком из десятка. Мне важны люди
Когда меня спросили ответить быстро, что я бы в идеале делал на работе, я за секунду сказал "рантайм" и "поиск". Things must work fast, и я вот никогда не был фанатом консистентности и транзакционности, хоть мне и пришлось эту науку освоитью. Я вот не верю во всякие биткойны, децентрализацию, зато ой как верю, что закон Мура выходит на плато и инновации в софте и железе будут важны как никогда. Мне важны проекты
В общем, этот блог никогда не обещал, что будет про технологии и вообще предназначался для друзей. Но раз вы до сюда дочитали, вот чем я развлекался последнюю неделю:
1. Ускорил компрессию LZ4 на где-то 3% для хорошо сжимаемых данных
https://github.com/lz4/lz4/pull/1079
Идея: в LZ семействе часто ищут совпадающие куски памяти, а когда находят, обновляют таблицу хешей:
a) memory compare, 8 bytes at a time
b) find matching trailing bytes through CTZ instructions (bsf, tzcnt on x86, ctz on ARM)
c) input_pointer += num_matching
d) load 4-5 bytes of updated input_pointer, update hashtable
Я вынашивал идею, которую сабмитил в snappy давно, что пункты b, c, d превращаются в цепочку. Поэтому, чтобы сократить цепочку зависимых событий, применяется трюк
b) find matching trailing bytes, read input_pointer + 4
c) shift either loaded tail or input_pointer + 4
Мейнтейнеру lz4 понравилось, попросил упростить код, посмотрим :). Удивительно, что даже в таком коде можно находить полуалгоритмические ускорения.
2. В процессорах M1 нашли интересные дизайн решения https://www.prefetchers.info/. Научились вытаскивать указатели, которые префетчатся для загрузки в дальнейшем. Это всё ещё не чтение данных, но возможный вектор атаки на space address randomization, который по умолчанию в MacOS. Статья написана изумительно хорошо, я с удовольствием прочитал
3. NSDI'22.
https://www.usenix.org/conference/nsdi22/presentation/mcclure.
https://www.usenix.org/system/files/nsdi22_slides_mcclure.pdf
Efficient Scheduling Policies for Microsecond-Scale Tasks.
Статья поднимает максимально больную тему в рантайме -- как балансировать между приоритетами быстрых тасок и каких-нибудь долгих джобов. Я видел это очень много в сервисах по типу новостей, ты либо много резервируешь, либо сильно страдаешь в коротких промежутках. Авторы в итоге много экспериментировали и поняли, что красть работу у ядер с долгими джобами очень хорошо, как и важна очень проактивная полиси для checkа, что ядра занимаются тем, чем надо. За это ты платишь парой процентов постоянно, но меньше страдаешь, когда происходят вспески работы. Эксперименты убедительны.
Такие дела, пойду дальше выгорать 🤷
Но я что-то интересное узнал про себя за последние 2 недели.
Я верю в свой проект, я верю в Google и Google Cloud. Но вот фактор людей у меня отняли на текущий момент, очень грустно. Ново пришедшие неинтересные какие-то, если честно. Tech Leadership меня вгоняет в тоску, когда мне интересно работать с одним человеком из десятка. Мне важны люди
Когда меня спросили ответить быстро, что я бы в идеале делал на работе, я за секунду сказал "рантайм" и "поиск". Things must work fast, и я вот никогда не был фанатом консистентности и транзакционности, хоть мне и пришлось эту науку освоитью. Я вот не верю во всякие биткойны, децентрализацию, зато ой как верю, что закон Мура выходит на плато и инновации в софте и железе будут важны как никогда. Мне важны проекты
В общем, этот блог никогда не обещал, что будет про технологии и вообще предназначался для друзей. Но раз вы до сюда дочитали, вот чем я развлекался последнюю неделю:
1. Ускорил компрессию LZ4 на где-то 3% для хорошо сжимаемых данных
https://github.com/lz4/lz4/pull/1079
Идея: в LZ семействе часто ищут совпадающие куски памяти, а когда находят, обновляют таблицу хешей:
a) memory compare, 8 bytes at a time
b) find matching trailing bytes through CTZ instructions (bsf, tzcnt on x86, ctz on ARM)
c) input_pointer += num_matching
d) load 4-5 bytes of updated input_pointer, update hashtable
Я вынашивал идею, которую сабмитил в snappy давно, что пункты b, c, d превращаются в цепочку. Поэтому, чтобы сократить цепочку зависимых событий, применяется трюк
b) find matching trailing bytes, read input_pointer + 4
c) shift either loaded tail or input_pointer + 4
a1 = read64(matched_p)В итоге цепочка получается меньше, так как процессор загружает ip+4, а не ip+matched. Проверка на нуль через cmov тоже легкая, потому что x86, что ARM умеют адресоваться к нижним частям регистров. См след картинку для демонстрации. Компиляторы не поняли, что cmov важен, поэтому приходится писать на ассемблере
a2 = read64(ip)
diff = a1 ^ a2;
matchedBits = CTZ(diff);
a3 = read64(ip + 4);
a2 = (U32)(diff) == 0 ? a3 : a2;
*last5Bytes = a2 >> (matchedBits & 24);
Мейнтейнеру lz4 понравилось, попросил упростить код, посмотрим :). Удивительно, что даже в таком коде можно находить полуалгоритмические ускорения.
2. В процессорах M1 нашли интересные дизайн решения https://www.prefetchers.info/. Научились вытаскивать указатели, которые префетчатся для загрузки в дальнейшем. Это всё ещё не чтение данных, но возможный вектор атаки на space address randomization, который по умолчанию в MacOS. Статья написана изумительно хорошо, я с удовольствием прочитал
3. NSDI'22.
https://www.usenix.org/conference/nsdi22/presentation/mcclure.
https://www.usenix.org/system/files/nsdi22_slides_mcclure.pdf
Efficient Scheduling Policies for Microsecond-Scale Tasks.
Статья поднимает максимально больную тему в рантайме -- как балансировать между приоритетами быстрых тасок и каких-нибудь долгих джобов. Я видел это очень много в сервисах по типу новостей, ты либо много резервируешь, либо сильно страдаешь в коротких промежутках. Авторы в итоге много экспериментировали и поняли, что красть работу у ядер с долгими джобами очень хорошо, как и важна очень проактивная полиси для checkа, что ядра занимаются тем, чем надо. За это ты платишь парой процентов постоянно, но меньше страдаешь, когда происходят вспески работы. Эксперименты убедительны.
Такие дела, пойду дальше выгорать 🤷