[c++] early returns vs instrucion cache

может подразумевается вызов большого кол-ва функций, которые не заинлайнены или функции, у которых первыми строками идет if (!param) return 1; и функции на них часто нарываются?

может подразумевается вызов большого кол-ва функций, которые не заинлайнены

с этим понятно, оно там подразумевается, оно так и есть

функции, у которых первыми строками идет if (!param) return 1; и функции на них часто нарываются?

ну то есть следует предпочитать конструкцию (2) конструкции (1)

//(1)
void foo() {
    if(!bar) { return; }
    /* some code */
}

//(2)
void foo() {
    if(bar) { 
        /* some code */ 
    }
}

эм... нарисовав код я, кажется, стал понимать откуда ноги растут :) большое спасибо

> эм... нарисовав код я, кажется, стал понимать откуда ноги растут :) большое спасибо

А я не понимаю. Почему это (1) хуже, чем (2)? В смысле, за счет чего производительность падает?
Я использую (1) потому, что так меньше вложенности и читать проще.

Какая-то херня с предсказанием ветвлений.

какие ещё предсказания? там код идентичный генерируется.

> а что там с «early returns»?

Преданья старины глубокой. Да и вообще - советы идиотские.

Чтобы так далеко зайти с оптимизацией надо уже хорошо знать целевую платформу, без этого получается ни о чем.

В ядре же много likely/unlikely используется, именно чтобы не инвертировать условие.

Хотя посмотрев код, уже сомневаюсь.

оба варианта говно. push, push, call, <save_stack_ptr>, <restore_stack_ptr>, ret, pop, pop

полезного кода не выполняется, а мусора навалом. инлайнить надо.

> эм... нарисовав код я, кажется, стал понимать откуда ноги растут :) большое спасибо

А я не понимаю. Почему это (1) хуже, чем (2)?

сравни код: в варианте (1) добавляется лишний return - нафиг он не нужен (по крайней мере в такой постановке задачи)

В смысле, за счет чего производительность падает?

вообще у меня есть мнение, что автор этой фразы просто некорректно высказался :)

какие ещё предсказания? там код идентичный генерируется.

как можно такое говорить, не имея кода вообще? О_о

Да и вообще - советы идиотские.

почему же?

Чтобы так далеко зайти с оптимизацией надо уже хорошо знать целевую платформу, без этого получается ни о чем.

ну почему же, это не такая уж тонкая материя

> как можно такое говорить, не имея кода вообще? О_о

ты наркоман штоле? я о твоём примере кода говорю.

> как можно такое говорить, не имея кода вообще? О_о

ты наркоман штоле? я о твоём примере кода говорю.

где там код? это просто шаблон, если его прогнать с -О3 там вообще ничего не останется наверное :)

или ты про тайный смысл

/* some code */

?

> где там код? это просто шаблон

и по этому шаблону, т.е. шаблонам, практически любой оптимизирующий компилятор даст одинаковый код, что бы там в /* some code */ не было.

похоже, ты просто компиляторов никогда не писал ;)

> Что скажут знатоки?

не знаток, но без конкретных примеров и замеров, показывающих какие-либо недостатки кода по скорости, с использованием конкретных компиляторов с включенной оптимизацией, такие советы - полная чушь, так можно и код, использующий RVO, например, предложить избегать

Питонисты, у которых вызов функции приводит к поиску в хеш таблице, смотрят с недоумением.

похоже, ты просто компиляторов никогда не писал ;)

теорию немножко знаю, а так - да, не писал :)

Интересно, а компиляторы умеют выносить некоторый код за пределы функции? Ну, то есть, частичный inline.

Да, умеют, особенно, когда эта функция в отдельном модуле.

Вручную это легко сделать с помощью макросов, чтобы сначала, например, проверялся параметр, а потом бы вызывалась именно функция.

А далее в коде бы это выглядело бы почти так же, как простой вызов функции.

Вручную это легко сделать с помощью макросов

Вручную это легко сделать и без макросов, просто разбиваешь функцию на две. Одна из них будет inline.

Вся фишка в том, чтобы это делал компилятор а программист был избавлен от ненужных мыслительных процессов.

Угу, и каждый раз тебе придется писать в коде две функции вместо одной. И наверняка один раз ошибка да случится: одну функцию пропустишь. А компилятор не сообщит об ошибке. А потом ВНЕЗАПНО…

Интересно, а компиляторы умеют выносить некоторый код за пределы функции? Ну, то есть, частичный inline.

нет, и слава богу :)

Угу, и каждый раз тебе придется писать в коде две функции вместо одной. И наверняка один раз ошибка да случится: одну функцию пропустишь.

copypaste is the root of all evil :)

вообще, если правильно писать, - не должно получаться так, что один и тот же код появляется в 2-х местах

А потом ВНЕЗАПНО…

ошибку поймают модульные тесты?

Balls. Правило 80/20 пока никто не отменял.

я не уверен что правильно понял Вас :)

Потому что уродовать код ради производительности - последняя стадия оптимизации.

Потому что уродовать код ради производительности - последняя стадия оптимизации.

почему же, уродовать? :) мне часто удобнее работать с точки зрения DOD, нежели городить правильную и строгую иерархию объектов, которую потом с мылом в попе надо будет ещё распараллеливать

Да на здоровье. Я только не завидую потом тем, кому потом придется ловить баги в твоем жутко оптимальном коде.

Я только не завидую потом тем, кому потом придется ловить баги в твоем жутко оптимальном коде.

и правильно, чего модульным тестам завидовать

между дрочим (с) если этот же код написать используя классический ООП-подход результат получится сложнее для понимания :)

и потом, я ж не такие «шишки» пишу:

static inline complexd operator~(complexd const & a) {
    static const union {
        int i[4]; __m128d v;
    } signbithigh = {0,0,0,0x80000000};

    return _mm_xor_pd(a, signbithigh.v);
}

Тебе виднее. В общем случае действует правило 80/20.

В общем случае действует правило 80/20.

80% кода пишутся 20% времени? :)

> почему же, уродовать? :) мне часто удобнее работать с точки зрения DOD, нежели городить правильную и строгую иерархию объектов

При чём тут иерархия объектов? В этих советах предлагают избегать вызова функций, чего можно достичь только вставкой тела вызываемой функции в вызывающую. Из чего со всей очевидностью проистекает то, что советы эти времен до появления inline, и то, что они идиотские.

В этих советах предлагают избегать вызова функций, чего можно достичь только вставкой тела вызываемой функции в вызывающую. Из чего со всей очевидностью проистекает то, что советы эти времен до появления inline, и то, что они идиотские.

вовсе и нет, там разное рекомендуется, но в числе прочего рекомендуется использовать inline (с умом конечно, не inline'ить всё что движется)

> с умом конечно, не inline'ить всё что движется

Тоже идиотизм, потому что inline - это запрос на встраивание, а не указание. Компилятор не обязан встраивать функцию.

> с умом конечно, не inline'ить всё что движется

Тоже идиотизм, потому что inline - это запрос на встраивание, а не указание. Компилятор не обязан встраивать функцию.

ты статью нашёл и читаешь, или просто там себе что-то придумал? скажи честно :)

> ты статью нашёл и читаешь

Щитоаа?!?

Я твои цитаты из нее комментирую. Буду я еще по ссылкам ходить...

Я твои цитаты из нее комментирую.

я здесь привёл только одну цитату, и Вы «комментируете» то, чего в той цитате впринципе нет

Буду я еще по ссылкам ходить...

каким ссылкам?

> я здесь привёл только одну цитату, и Вы «комментируете» то, чего в той цитате впринципе нет

А вот это там есть:

в числе прочего рекомендуется использовать inline

Вот его-то я и комментирую.

каким ссылкам?

Да какая разница по каким?!

> в числе прочего рекомендуется использовать inline

Вот его-то я и комментирую.

так это не цитата, это моя прямая речь

> каким ссылкам?

Да какая разница по каким?!

в этом треде ссылок нет (с)

> так это не цитата, это моя прямая речь

Не цепляйся к словам.

> в этом треде ссылок нет (с)

Ах, еще и ссылок нет?!!

> с умом конечно, не inline'ить всё что движется

Тоже идиотизм, потому что inline - это запрос на встраивание, а не указание. Компилятор не обязан встраивать функцию.

уж раз пошла такая пианка отвечу

писать везде inline - вот это реально засада-подстава, да компилятор сам решает что инлайнить, а что нет, но во-первых чтобы получить хорошую оптимизацию ему надо давать указания что ты хочешь получить, а не в угадай мелодию играть, а во-вторых многое из того что инлайнить не рекомендуется может быть таки заинлайнено, и в-третьих я, похрустывая попкорном, посмотрю на Ваши танцы с бубном, когда у Вас будет больше одного компилятора

ну знаете, этак можно назвать оппонента, к примеру, говном, а потом, когда он начнёт возмущаться, сказать, что тот к словам цепляется :)

> в этом треде ссылок нет (с)

Ах, еще и ссылок нет?!!

один шаг до настоящего Ъ :)

а смысл в inline ? если при оптимизации по скорости и так как выразился shty «инлайнится все что движется» ну кроме очень больших функций мы же все равно включаем оптимизацию для релизной версии