AP
Условные переходы не мешают процессору делать префетчинг и спекулятивное выполнение. Но процессор вынужден угадывать, по какой ветке пойдёт выполнение, а это не всегда получается
Size: a a a
2020 October 31
D
Ну вообще да, имелось в виду, что безусловный переход - угадывается всегда, а условный - нет, и это ведет свои изджержки при неугадывании, в т.ч и кеш страдает и кеш инструкций, а не только Л1-3кеши.
А какое отношение к вопросу о влиянии
goto на производительность имеют условные переходы?)I
А какое отношение к вопросу о влиянии
goto на производительность имеют условные переходы?)ну просто готу это безусловный переход, как я понимаю и я его сравнил с условным, чисто для сравнения и объяснения какие механизмы задействуются и вовлекаются в процесс, а с чем еще сравнивать, говоря о перфомансе? с call?
ПК
IA
Частично офтоп, но все же к вопросу о условных переходах, в 20 стандарте были введены новые атрибуты, в том числе они коснулись условных переходов, по идеи теперь можно помечать ветки if как часто используемые или же наооборот редко используемые, и на основе этих данных компиляторы должны оптимизировать выполнение однако я не в курсе реализовано ли это уже в компиляторах, хотя бы в бета версии, сильно не слежу мне и 17 с головой пока хватает)😃😂
EZ
Частично офтоп, но все же к вопросу о условных переходах, в 20 стандарте были введены новые атрибуты, в том числе они коснулись условных переходов, по идеи теперь можно помечать ветки if как часто используемые или же наооборот редко используемые, и на основе этих данных компиляторы должны оптимизировать выполнение однако я не в курсе реализовано ли это уже в компиляторах, хотя бы в бета версии, сильно не слежу мне и 17 с головой пока хватает)😃😂
Программист часто думает что он умнее компилятора и процессора, обычно это не так
И
Частично офтоп, но все же к вопросу о условных переходах, в 20 стандарте были введены новые атрибуты, в том числе они коснулись условных переходов, по идеи теперь можно помечать ветки if как часто используемые или же наооборот редко используемые, и на основе этих данных компиляторы должны оптимизировать выполнение однако я не в курсе реализовано ли это уже в компиляторах, хотя бы в бета версии, сильно не слежу мне и 17 с головой пока хватает)😃😂
В компиляторах это уже давно поддерживается. Например, gcc уже давно предлагает использовать __glibc_unlikely и ему подобные вещи для этих целей
IA
Программист часто думает что он умнее компилятора и процессора, обычно это не так
И не подумаю спорить, однозначно так тут и говорить не о чем, но как по мне это имеет смысл существует ситуации когда определенные логические ветки ичпользуються ну уж крайне редко, вот если говорить о реальном коде то есть как минимум одно место в моем коде сейчас где я бы это приминил, я занимаюсь 3d печатью, и одна из задач которую стоит оптимизировать это разрезать треугольник на слои, так вот почти всегда в разрезе 2 точки, но существуют крайне редкие случаи когда слой попадает на вершину треугольника, и есть отдельная ветка которая описывает поведение в этом случае, она за сесию может и не вызваться не разу или вызоветься 5-6 раз против милионов вызовов когда в разрезе 2 точки, в таком случае, то почему бы и не пометить ветку как редко используемую и не дать компилятору возможность ее оптимизировать, хотя откровенно говоря для меня загадка в чем заключаетьсч оптимизация, и в чем это дает выигрыш)
EZ
И не подумаю спорить, однозначно так тут и говорить не о чем, но как по мне это имеет смысл существует ситуации когда определенные логические ветки ичпользуються ну уж крайне редко, вот если говорить о реальном коде то есть как минимум одно место в моем коде сейчас где я бы это приминил, я занимаюсь 3d печатью, и одна из задач которую стоит оптимизировать это разрезать треугольник на слои, так вот почти всегда в разрезе 2 точки, но существуют крайне редкие случаи когда слой попадает на вершину треугольника, и есть отдельная ветка которая описывает поведение в этом случае, она за сесию может и не вызваться не разу или вызоветься 5-6 раз против милионов вызовов когда в разрезе 2 точки, в таком случае, то почему бы и не пометить ветку как редко используемую и не дать компилятору возможность ее оптимизировать, хотя откровенно говоря для меня загадка в чем заключаетьсч оптимизация, и в чем это дает выигрыш)
Ну branch predictor должен с такой штукой практически идеально справляться
IA
А, или вопрос был про поддержку стандартных стредств языка, а не компиляторозависимых расширений? Тогда прошу прощения
Да вроде того, тоесть теоретически это введено теперьв стандарт (с 20 года) и поддерживаеться всеми компиляторами в равной мере)
IA
Ну branch predictor должен с такой штукой практически идеально справляться
Возможно
IA
Только я все равно совершенно не понимаю на основе чего он делает вывод какая ветка более используема
EZ
Только я все равно совершенно не понимаю на основе чего он делает вывод какая ветка более используема
Кто, бранч предиктор? На основании истории
CD
Кто, бранч предиктор? На основании истории
Это если его из-за очередного мелтдауна не выключили
EZ
Это если его из-за очередного мелтдауна не выключили
Нууу
I
Это если его из-за очередного мелтдауна не выключили
мелтдаун позволял читать память чужого процесса, не думаю, что тут надо выключать предиктор. Скорее как то кеши синхронизировать по доступу - но никто бренч предиктор не выключал, это точно. Бренч миспридикшн это дорого - если есть возможность обойтись без перехода условного, лучше обойтись без него., скажем умножать на ноль или единицу.