Прочитал тут в одном очень классном техническом блоге пост о том, что не стоит надеяться на бранч предиктор в случае очень редко срабатываемых условий, что все равно будет сильная просадка производительности, если такие не срабатывающие проверки всюду вставлять (на примере Rust-а говорилось о 20% просадки в случае такой проверки в горячем цикле).
И хотя с таким трудно не согласиться (конечно же даже не срабатывающая проверка все еще занимает время), я тут же вспомнил про обратную сторону медали: ситуацию, когда люди наоборот, совершенно не верят в branch prediction и строят целые архитектуры вокруг этого неверия. И я был среди них!
—
Яркий пример такой ситуации – это реализация safe-points во многих виртуальных машинах для managed языков. Концептуально safe-point – это точка в коде, в которой поток может кооперативно приостановиться по запросу VM. Например, для сборки мусора или вытеснения легковесного потока, но в целом для чего угодно.
А как safe-point реализовать? Простейшее решение – polling, т.е. явная проверка глобального флага, который при необходимости выставит VM, и последующий переход в обработчик. Но если вы посмотрите на код, генерируемый C2, то на какой-нибудь обратной дуге цикла сможете наблюдать вот такую инструкцию:
Результат (флаги) инструкции игнорируются. Как вы уже догадались, это известная оптимизация через trap-based схему: пока потоку останавливаться не нужно, мы здесь разыменовываем что-то безобидное (что дешево), а когда пора тормозить, соответствующая страница в памяти становится защищенной на чтение, после чего случается трап. Он в свою очередь перехватывается в рантайме, и поток приостанавливается.
Действительно, кажется, что trap-based – это подходящая здесь оптимизация, ведь мы без всякого барнч предиктора знаем, что проверки редко срабатывают, так что лучше мы замедлим случай, когда они таки сработают (и замедлим сильно), но ускорим fast path. Эта оптимизация с нами настолько давно (вот еще Ole Agesen пишет про нее в 98-ом году), что ее использование считается такой абсолютной общепринятой истинной. Ну вот надо делать трапы и все тут, так положено, так заведено.
Но у такой оптимизации есть и обратная сторона, и имя ей trap storm. Если у вас слишком много потоков, в которых одновременно срабатывает трап, то вы можете столкнуться с очень неприятными фризами всей системы. Это известная проблема, например, вот здесь (чуть в другом контексте) про нее говорят создатели сборщика мусора C4.
И вот спрашивается, а точно ли нужно вручную оптимизировать редко срабатывающие бранчи такой ценой? Несколько лет назад я впервые услышал мнение Клиффа Клика, что это абсолютно не нужно: современные бранч предикторы прекрасно справляются и сами, если оставить polling просадка производительности будет почти незаметной, так что нечего мудрить. Я тогда ооочень удивился и даже проворчал что-то типа "ну да, ну да, конечно, как же!". Но чем дальше, тем чаще я слышал такую точку зрения. Вот здесь, например, тоже самое утверждает Gil Tene (ну т.е. крутые люди повторяют эту мысль).
И вот, не так давно мы и сами проверили, подготовив версию VM с polling вместо trap-based safe-points. И знаете, какое мы увидели влияние на бенчи? Никакого. Вообще. Все просто в рамках погрешности. Так что пришлось и мне уверовать в мастерство бранч предиктора. На самом деле это прекрасно, реализация через polling резко увеличивает функциональность safe-point, там можно много чего другого сразу сделать.
—
Мы системные программисты довольно консервативны и не любим полагаться на высшие силы. Все-то нам нужно контролировать, все дооптимизировать руками (вы бы видели количество явных указаний для инлайна в нашем рантайме, боже). Но иногда и нам стоит чуть отпустить контроль, иначе рискуем застрять в средневековье.
—
В чем я согласен с автором оригинального поста, так это в том, что если проверку можно легально убрать, то стоит это делать. Или путем написания идиоматического кода, или же корректной оптимизацией. Но если проверка неизбежна, то верим в бранч предиктор.
#дух_машины
И хотя с таким трудно не согласиться (конечно же даже не срабатывающая проверка все еще занимает время), я тут же вспомнил про обратную сторону медали: ситуацию, когда люди наоборот, совершенно не верят в branch prediction и строят целые архитектуры вокруг этого неверия. И я был среди них!
—
Яркий пример такой ситуации – это реализация safe-points во многих виртуальных машинах для managed языков. Концептуально safe-point – это точка в коде, в которой поток может кооперативно приостановиться по запросу VM. Например, для сборки мусора или вытеснения легковесного потока, но в целом для чего угодно.
А как safe-point реализовать? Простейшее решение – polling, т.е. явная проверка глобального флага, который при необходимости выставит VM, и последующий переход в обработчик. Но если вы посмотрите на код, генерируемый C2, то на какой-нибудь обратной дуге цикла сможете наблюдать вот такую инструкцию:
test DWORD PTR [rip+0xfffffffff3d41c17],eax
Результат (флаги) инструкции игнорируются. Как вы уже догадались, это известная оптимизация через trap-based схему: пока потоку останавливаться не нужно, мы здесь разыменовываем что-то безобидное (что дешево), а когда пора тормозить, соответствующая страница в памяти становится защищенной на чтение, после чего случается трап. Он в свою очередь перехватывается в рантайме, и поток приостанавливается.
Действительно, кажется, что trap-based – это подходящая здесь оптимизация, ведь мы без всякого барнч предиктора знаем, что проверки редко срабатывают, так что лучше мы замедлим случай, когда они таки сработают (и замедлим сильно), но ускорим fast path. Эта оптимизация с нами настолько давно (вот еще Ole Agesen пишет про нее в 98-ом году), что ее использование считается такой абсолютной общепринятой истинной. Ну вот надо делать трапы и все тут, так положено, так заведено.
Но у такой оптимизации есть и обратная сторона, и имя ей trap storm. Если у вас слишком много потоков, в которых одновременно срабатывает трап, то вы можете столкнуться с очень неприятными фризами всей системы. Это известная проблема, например, вот здесь (чуть в другом контексте) про нее говорят создатели сборщика мусора C4.
И вот спрашивается, а точно ли нужно вручную оптимизировать редко срабатывающие бранчи такой ценой? Несколько лет назад я впервые услышал мнение Клиффа Клика, что это абсолютно не нужно: современные бранч предикторы прекрасно справляются и сами, если оставить polling просадка производительности будет почти незаметной, так что нечего мудрить. Я тогда ооочень удивился и даже проворчал что-то типа "ну да, ну да, конечно, как же!". Но чем дальше, тем чаще я слышал такую точку зрения. Вот здесь, например, тоже самое утверждает Gil Tene (ну т.е. крутые люди повторяют эту мысль).
И вот, не так давно мы и сами проверили, подготовив версию VM с polling вместо trap-based safe-points. И знаете, какое мы увидели влияние на бенчи? Никакого. Вообще. Все просто в рамках погрешности. Так что пришлось и мне уверовать в мастерство бранч предиктора. На самом деле это прекрасно, реализация через polling резко увеличивает функциональность safe-point, там можно много чего другого сразу сделать.
—
Мы системные программисты довольно консервативны и не любим полагаться на высшие силы. Все-то нам нужно контролировать, все дооптимизировать руками (вы бы видели количество явных указаний для инлайна в нашем рантайме, боже). Но иногда и нам стоит чуть отпустить контроль, иначе рискуем застрять в средневековье.
—
В чем я согласен с автором оригинального поста, так это в том, что если проверку можно легально убрать, то стоит это делать. Или путем написания идиоматического кода, или же корректной оптимизацией. Но если проверка неизбежна, то верим в бранч предиктор.
#дух_машины
Telegram
Алиса копается
"Редко исполняющиеся ифы почти бесплатны"
Нет. Да, процессоры по большей части умеют эффективно обрабатывать редко исполняющиеся условные прыжки. Но вам всё ещё нужно считать условие if, даже если оно постоянно оказывается false. Если вы перед каждым обращением…
Нет. Да, процессоры по большей части умеют эффективно обрабатывать редко исполняющиеся условные прыжки. Но вам всё ещё нужно считать условие if, даже если оно постоянно оказывается false. Если вы перед каждым обращением…
🔥21👌1
В Новосибирске тропические ливни, в Пашино лепреконы 🍀
❤14😍3
Алло, это отладочная?
Всеобщая серость, при нашем то уровне
Летом по сути та же серость, но с зеленью 🌿
❤13
Случайно наткнулся на доклад Ани Барски 12-летней давности, где она рассказывает о становлении Java в 90-ые и организации центра разработки Sun Microsystems в Питере в начале двухтысячных.
Интересный рассказ из далекого прошлого о еще более далеком прошлом. Сегодня звучит, конечно, как древнегреческий эпос об эпохе героев. Но некоторые мотивы очень знакомы, например о том, и как корпорации воют за целые команды российских инженеров (в ее рассказе это битва Sun vs Intel за сотрудников МЦСТ, как же иронично, что через 15 лет аналогичная битва шла уже за осколки Intel, а еще позже за оставшихся сотрудников JB и Азула).
Вообще, у меня лично две мысли после просмотра остались:
1) Нужно таки кому-то оформить рассказ про альтернативную историю Java в России. Недавно был доклад от Леши Федорова и Володи Воскресенского на тему истории Java в России вообще (он, кстати, сильно пересекается с докладом Ани Барски), но там вообще почти ничего не сказано про то, что происходило здесь в Новосибе, в Excelsior (а это супер драматичная история, по моему скромному мнению не уступающая по накалу страстей и эпичности питерским историям, а во многом превосходящая их).
2) Я скучаю по миру Java, а точнее по миру разработки JVM. Все-таки там было очень круто.
Интересный рассказ из далекого прошлого о еще более далеком прошлом. Сегодня звучит, конечно, как древнегреческий эпос об эпохе героев. Но некоторые мотивы очень знакомы, например о том, и как корпорации воют за целые команды российских инженеров (в ее рассказе это битва Sun vs Intel за сотрудников МЦСТ, как же иронично, что через 15 лет аналогичная битва шла уже за осколки Intel, а еще позже за оставшихся сотрудников JB и Азула).
Вообще, у меня лично две мысли после просмотра остались:
1) Нужно таки кому-то оформить рассказ про альтернативную историю Java в России. Недавно был доклад от Леши Федорова и Володи Воскресенского на тему истории Java в России вообще (он, кстати, сильно пересекается с докладом Ани Барски), но там вообще почти ничего не сказано про то, что происходило здесь в Новосибе, в Excelsior (а это супер драматичная история, по моему скромному мнению не уступающая по накалу страстей и эпичности питерским историям, а во многом превосходящая их).
2) Я скучаю по миру Java, а точнее по миру разработки JVM. Все-таки там было очень круто.
YouTube
Аня Барски — Java Life Story
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Конференция JPoint 2013
Аня Барски, Azul Systems — Java Life Story
Санкт-Петербург, 05.04.2013
"Для многих из нас технологии становятся…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Конференция JPoint 2013
Аня Барски, Azul Systems — Java Life Story
Санкт-Петербург, 05.04.2013
"Для многих из нас технологии становятся…
❤21
кайф, уже два рабочих митинга зашедулили на первую неделю моего отпуска 🤡
ну так что же: я буду подключаться на них исключительно из шезлонга, на фоне моря и с включенной камерой.
ну так что же: я буду подключаться на них исключительно из шезлонга, на фоне моря и с включенной камерой.
😁21❤9🙈5👍2
Алло, это отладочная?
кайф, уже два рабочих митинга зашедулили на первую неделю моего отпуска 🤡 ну так что же: я буду подключаться на них исключительно из шезлонга, на фоне моря и с включенной камерой.
конечно же, когда я писал это хвастливое сообщение, я забыл про блядские ТАЙМЗОНЫ и про то, что митинг в результате начнется в 4 утра.
ну, митинг закончился, всё утвердили, вот и утро, можно на море собираться 🏖️
ну, митинг закончился, всё утвердили, вот и утро, можно на море собираться 🏖️
😢19😁5🤓1
Сейчас такое время, что многие абитуриенты новоиспеченные первокурсники спрашивают, как им подготовиться к первому курсу? Что почитать? Что доучить?
Недавно в одном чатике высказал по этому поводу, как мне кажется, полнейшую базу, перепощу ее и сюда:
Когда-то мне эту мысль подсказал @cypok, с тех пор я с ней абсолютно согласен и всячески пропагандирую.
Всем лето, друзья! А поступившим сегодня в университет – поздравления 🎉
P.S. про приемную компанию на сиспро в этом году напишу чуть позже, там интересно, драматично и хорошо
Недавно в одном чатике высказал по этому поводу, как мне кажется, полнейшую базу, перепощу ее и сюда:
Непопулярное мнение: чтобы быть хоть немного готовым к первому курсу… сейчас стоит хорошенько отдохнуть. Гулять, встречаться с друзьями, ходить на море или делать что угодно, что вам нравится, не думая об учебе.
Возможность (и необходимость) попахать у вас еще будет, при том в огромном количестве. А вот возможность отдохнуть и подзарядиться очень ценна, не стоит ее упускать.
Когда-то мне эту мысль подсказал @cypok, с тех пор я с ней абсолютно согласен и всячески пропагандирую.
Всем лето, друзья! А поступившим сегодня в университет – поздравления 🎉
P.S. про приемную компанию на сиспро в этом году напишу чуть позже, там интересно, драматично и хорошо
🔥25💯9