Как стать автором
Обновить

«Чтобы вылезти выше среднего, нужна какая-то мотивация за пределами денег» — интервью с Русланом Черёминым

Время на прочтение16 мин
Количество просмотров29K
Всего голосов 43: ↑39 и ↓4+35
Комментарии7

Комментарии 7

Но никто эту работу не делал. И уже потом я читал чей-то горячий код — то ли это быk код Aeron-a, который всё там делал, то ли Chronicle Map Питера Лори.

Если это и было что-то, связанное с Chronicle, то скорее это был проект Chronicle Wire (позиционируется как аналог/конкурент SBE), который очень сильно опирается на лямбды как в АПИ, так и внутренней реализации, и рассчитывает что они не будут аллоцироваться. Питер года полтора назад много с этим экспериментировал и писал, например см. http://vanillajava.blogspot.com/2015/01/java-lambdas-and-low-latency.html


В Chronicle Map как раз противоположный подход — все до последнего объекта кешируется в threadLocal, что по скорости хуже, потому что такие объекты точно не могут быть скаляризованы.

Нет, это не лямбды Питера, это был очень простой метод, который возвращал пару объектов, заворачивая их в что-то вроде Pair. Что-то вроде метода lookup, который возвращает найденный объект + индекс позиции для вставки, если объекта нет. Пост Питера про лямбды я увидел уже позже.

И, кстати, у Питера странные вещи написаны: XX:MaxBCEAEstimateSize (как и все остальные ключи с BCEA) — это параметр _меж_процедурного EA, который используется не для скаляризации, а для lock elision. Почему это флаг у него как-то повлиял на скаляризацию (и действительно повлияло ли) — это большой вопрос.

Честно говоря, не могу такого припомнить в Chronicle Map, даже ранних версиях. Что-то подобное было (и есть) и Trove и ранних версиях koloboke, почти 3 года назад: https://m.habrahabr.ru/post/192186/


Если это было в Chronicle Map, то не потому, что мы увидели, что там 100% скаляризация, а просто потому, что это было удобно для определенного DRY. Никто в Chronicle Map никогда на скаляризацию не смотрел. Ты сильно переоцениваешь уровень аналитики, который стоит за кодом этого проекта.

Тогда я не догадался записать, что за код смотрел, так что теперь уже точно не скажешь. Но было бы забавно, если я смотрел код, который автор просто забил/не успел соптимизировать — а я решил, что там умнейшая закладка на скаляризацию, и сел копать эту тему :)

Что касается BCEA — все вопросы к Питеру, я в эту тему даже не смотрел.

— На эту тему есть целая школа— в Скандинавии, кажется. Там один мужик сделал крутую штуку: ты запускаешь определённый набор тестов, и он по результатам бенчмарков строит модель того, как устроен твой процессор. То есть он пытается их по-разному гонять и за счёт этого строит предположение о том, какой здесь кэш — общий или нет, сколько ядер и так далее. И это, получается, тот подход, который на основе бенчмарков пытается понять, что там в реальности.

@23derevo не Агнера Фога ли ты имеешь ввиду? Честно говоря, то, что он пишет, больше похоже на контролируемую поставку. Не верю, что можно в таких деталях воссоздать, например, алгоритм предсказателя переходов, основываясь только на бенчах

Если ты про третью главу «The microarchitecture of Intel, AMD and VIA CPUs», то я охотно верю, что всю информацию оттуда можно собрать из открытых источников и бенчмарков. Идеи алгоритмов обычно открыто опубликованы (он приводит ссылки на научные статьи и патенты), а детали уже можно вытащить с помощью бенчмарков.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий