менять наверное не стоит. Доступ к элементу массива наверное не дольше чем доступ к локальной переменной, а вот инициализация переменной наверное немного вреаени сожрёт. Да и читаемость текста ухудшается...
Здравствуйте, KinK, Вы писали:
KK>Оптимизируют ли компиляторы (в частности Visual C++ 6.0) такой код:
KK>
KK>if (f(z))
KK> x = y + f(z);
KK>
KK>или есть смысл заменять его на
KK>
KK>if (tmp = f(z))
KK> x = y + tmp;
KK>
KK>Наверное не оптимизирует, так как теоретически функция может выдавать разные значения при одном и том же аргументе. Придётся в ручную это делать?
VC6.0 такое не оптимизирует, если это действительно вызов функции, а не константный макрос. инлайны когда выход зависит от входа тоже не оптимизирует
хочешь убедиться — компиляй с генерацией асм кода построчно на код с++
Здравствуйте, KinK, Вы писали:
KK>Здравствуйте, Анатолий Широков, Вы писали:
АШ>>Есть смысл.
KK>А вот это:
KK>
KK>if (obj[j].arr[z])
KK> x = y + obj[j].arr[z];
KK>
KK>на это:
KK>
KK>if (tmp = obj[j].arr[z])
KK> x = y + tmp;
KK>
KK>менять наверное не стоит. Доступ к элементу массива наверное не дольше чем доступ к локальной переменной, а вот инициализация переменной наверное немного вреаени сожрёт. Да и читаемость текста ухудшается...
Интересно что если в объекте массив прячем и организуем доступ через public функцию CObj::GetArr(z){return arr[z];}, то оптимизировать придётся...
Здравствуйте, KinK, Вы писали:
KK>Оптимизируют ли компиляторы (в частности Visual C++ 6.0) такой код:
KK>
KK>if (f(z))
KK> x = y + f(z);
KK>
KK>или есть смысл заменять его на
KK>
KK>if (tmp = f(z))
KK> x = y + tmp;
KK>
KK>Наверное не оптимизирует, так как теоретически функция может выдавать разные значения при одном и том же аргументе. Придётся в ручную это делать?
Да, придется. В GCC, например, для этого есть специальный модификатор, который позволяет явно сказать компилятору, что данную функцию можно вот так оптмизировать.
Best regards,
Андрей Тарасевич
Re: Оптимизация
От:
Аноним
Дата:
06.02.07 08:17
Оценка:
Здравствуйте, KinK, Вы писали:
Сейчас не могу воспроизвести за давностью, но мне приходилось видеть, что в выражении вида ...sin(x)*sin(x)*... синус вычислялся один раз. Но там для этого использовались команды FPP, если же это настоящая функция, то компилятор вряд ли догадается что у нее нет побочных эффектов.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, KinK, Вы писали:
А>Сейчас не могу воспроизвести за давностью, но мне приходилось видеть, что в выражении вида ...sin(x)*sin(x)*... синус вычислялся один раз. Но там для этого использовались команды FPP, если же это настоящая функция, то компилятор вряд ли догадается что у нее нет побочных эффектов.
С sin все гораздо проще — синтаксис и СЕМАНТИКА компилятору известны. В отличие от пользовательских. MSVC7.1 иногда излишне переусердствует:
[сcode] m->x = rand(); m->y = rand();
//rand called once
[/сcode]
Не всегда, и не в простейших случаях, но иногда "выкидывает" трюк.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
KK>if (obj[j].arr[z])
KK> x = y + obj[j].arr[z];
KK>
KK>на это:
KK>if (tmp = obj[j].arr[z])
KK> x = y + tmp;
KK>
KK>менять наверное не стоит.
Стоит, я бы даже так написал:
tmp = obj[j].arr[z];
if (tmp != 0)
x = y + tmp;
KK>Доступ к элементу массива наверное не дольше чем доступ к локальной переменной, а вот инициализация переменной наверное немного вреаени сожрёт. Да и читаемость текста ухудшается...
Доступ к элементу массива дольше, чем доступ к локальной переменной. Переменная может и в регистре процессора храниться, а за массивом нужно в память лезть... А читаемость по-моему ничуть не хуже.
PS:
Ассемблерный листинг, выдаваемый компилятором — лучший помощник при оптимизации.
KK>>if (tmp = obj[j].arr[z])
KK>> x = y + tmp;
KK>>
AA>Стоит, я бы даже так написал:
AA>
AA>tmp = obj[j].arr[z];
AA>if (tmp != 0)
AA> x = y + tmp;
AA>
А чем это лучше моего?
AA>Доступ к элементу массива дольше, чем доступ к локальной переменной. Переменная может и в регистре процессора храниться, а за массивом нужно в память лезть... А читаемость по-моему ничуть не хуже.
Согласен. Но тогда компилятор по хорошему должен догадаться и сам соптимизировать, тут ведь подводных камней вроде нет.
KK>>>if (tmp = obj[j].arr[z])
KK>>> x = y + tmp;
KK>>>
AA>>Стоит, я бы даже так написал:
AA>>
AA>>tmp = obj[j].arr[z];
AA>>if (tmp != 0)
AA>> x = y + tmp;
AA>>
KK>А чем это лучше моего?
Четко видно, что именно проверяется.
AA>>Доступ к элементу массива дольше, чем доступ к локальной переменной. Переменная может и в регистре процессора храниться, а за массивом нужно в память лезть... А читаемость по-моему ничуть не хуже. KK>Согласен. Но тогда компилятор по хорошему должен догадаться и сам соптимизировать, тут ведь подводных камней вроде нет.
Здравствуйте, AleX AciD, Вы писали:
KK>>Согласен. Но тогда компилятор по хорошему должен догадаться и сам соптимизировать, тут ведь подводных камней вроде нет. AA>На компилятор надейся, а сам не плошай
ИМХО, забивать голову не нужными оптимизациями не стоит!
Пусть обезьянью работу машина делает! А самому оптимизировать стоит то, что машине не под силу.
А читаемость по-моему ничуть не хуже. 
