Здравствуйте, vdimas, Вы писали:
SM>>и где теперь ваши регистры?
V>хе, причем тут регистры??? V>убирать тупиковый код или "склеивать" константы умел еще Borland C++ 3.1
V>вставь вызовы каких-нить внешних ф-й, "разбавь" код и экспериментируй на здоровье дальше.
речь идет о том, как register поможет оптимизировать. Приведеный пример показывает, что компилятор игнорирует в некоторых случаях это ключевое слово.
Здравствуйте, Faust, Вы писали:
SM>>тогда надо ответить (прежде всего себе) не несколько вопросов: SM>>1. сколько времени выполняется программа? F>фоновой режим
т.е. бесконечно долго?
SM>>2. удовлетворяет ли Вас это время? F>в данном случае(фоновой режим) вопрос некорректен SM>>3. какая часть времени тратиться на данную ф-ию? F>10000 вызовов укладывается в 70 мс SM>>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы F>безусловно. F>
F>// глупо использовать следующий неоптимизированный код
F>int n = 3;
F>int k = 34;
F>int g = 765;
F>int m = (n + k) + (n + k - g);
F>// вместо
F>int n = 3;
F>int k = 34;
F>int g = 765;
F>int m = ((n << 1) + (k << 1)) - g;
F>// даже если это не критический участок кода
F>
это наивный взгляд на компиляцию. коды будут одинаковые! и поэтому первый вариант предпочтительней, т.к. отражает (видимо) алгоритм.
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
SM>>>тогда надо ответить (прежде всего себе) не несколько вопросов: SM>>>1. сколько времени выполняется программа? F>>фоновой режим
SM>т.е. бесконечно долго?
SM>>>2. удовлетворяет ли Вас это время? F>>в данном случае(фоновой режим) вопрос некорректен SM>>>3. какая часть времени тратиться на данную ф-ию? F>>10000 вызовов укладывается в 70 мс SM>>>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы F>>безусловно. F>>
F>>// глупо использовать следующий неоптимизированный код
F>>int n = 3;
F>>int k = 34;
F>>int g = 765;
F>>int m = (n + k) + (n + k - g);
F>>// вместо
F>>int n = 3;
F>>int k = 34;
F>>int g = 765;
F>>int m = ((n << 1) + (k << 1)) - g;
F>>// даже если это не критический участок кода
F>>
SM>это наивный взгляд на компиляцию. коды будут одинаковые! и поэтому первый вариант предпочтительней, т.к. отражает (видимо) алгоритм.
соглашусь только с выделенным, т.к. в некоторых случаях необходимо передать код другим разработчикам, но я бы в етом случае сделал так.
int n = 3;
int k = 34;
int g = 765;
// m = (n + k) + (n + k - g);int m = ((n << 1) + (k << 1)) - g;
SM>время ручной оптимизации такого уровня прошло!
я думаю, мы останемся при своих мнениях
В любом случае спасибо за участие
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Здравствуйте, SergeMukhin, Вы писали:
SM>>>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы F>>безусловно. F>>
F>>// глупо использовать следующий неоптимизированный код
F>>int n = 3;
F>>int k = 34;
F>>int g = 765;
F>>int m = (n + k) + (n + k - g);
F>>// вместо
F>>int n = 3;
F>>int k = 34;
F>>int g = 765;
// не самый лучший и не самый наглядный пример. ТУПЛЮ
F>>int m = ((n << 1) + (k << 1)) - g;
// вот как нужноint m = ((n + k) << 1) - g;
F>>// даже если это не критический участок кода
F>>
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
SM>>это наивный взгляд на компиляцию. коды будут одинаковые! и поэтому первый вариант предпочтительней, т.к. отражает (видимо) алгоритм. F>соглашусь только с выделенным, т.к. в некоторых случаях необходимо передать код другим разработчикам, но я бы в етом случае сделал так. F>
F>int n = 3;
F>int k = 34;
F>int g = 765;
F>// m = (n + k) + (n + k - g);
F>int m = ((n << 1) + (k << 1)) - g;
F>
можно не соглашаться с фразой, что коды будут одинаковыми, но они от этого все равно будут одинаковыми! (для Microsoft (R) Incremental Linker Version 7.10.3077)
Здравствуйте, Faust, Вы писали:
F>Здравствуйте, SergeMukhin, Вы писали:
SM>>>>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы F>>>безусловно. F>>>
F>>>// глупо использовать следующий неоптимизированный код
F>>>int n = 3;
F>>>int k = 34;
F>>>int g = 765;
F>>>int m = (n + k) + (n + k - g);
F>>>// вместо
F>>>int n = 3;
F>>>int k = 34;
F>>>int g = 765;
F>// не самый лучший и не самый наглядный пример. ТУПЛЮ
F>>>int m = ((n << 1) + (k << 1)) - g;
F>// вот как нужно
F>int m = ((n + k) << 1) - g;
F>>>// даже если это не критический участок кода
F>>>
не поленился и проверил. Все три варианта (переменные n,k,g передаем только через параметры, а то вообще в константу свернется) генерят ОДИН И ТОТ ЖЕ код! Надо ли оптимизировать в ручную?
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
SM>>>это наивный взгляд на компиляцию. коды будут одинаковые! и поэтому первый вариант предпочтительней, т.к. отражает (видимо) алгоритм. F>>соглашусь только с выделенным, т.к. в некоторых случаях необходимо передать код другим разработчикам, но я бы в етом случае сделал так. F>>
F>>int n = 3;
F>>int k = 34;
F>>int g = 765;
F>>// m = (n + k) + (n + k - g);
F>>int m = ((n << 1) + (k << 1)) - g;
F>>
SM>можно не соглашаться с фразой, что коды будут одинаковыми, но они от этого все равно будут одинаковыми! (для Microsoft (R) Incremental Linker Version 7.10.3077)
ты забыл про портируемость и про существование других компиляторов
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
F>>Здравствуйте, SergeMukhin, Вы писали:
SM>>>>>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы F>>>>безусловно. F>>>>
F>>>>// глупо использовать следующий неоптимизированный код
F>>>>int n = 3;
F>>>>int k = 34;
F>>>>int g = 765;
F>>>>int m = (n + k) + (n + k - g);
F>>>>// вместо
F>>>>int n = 3;
F>>>>int k = 34;
F>>>>int g = 765;
F>>// не самый лучший и не самый наглядный пример. ТУПЛЮ
F>>>>int m = ((n << 1) + (k << 1)) - g;
F>>// вот как нужно
F>>int m = ((n + k) << 1) - g;
F>>>>// даже если это не критический участок кода
F>>>>
SM>не поленился и проверил. Все три варианта (переменные n,k,g передаем только через параметры, а то вообще в константу свернется) генерят ОДИН И ТОТ ЖЕ код! Надо ли оптимизировать в ручную? На компилятор надейся, но и сам не плошай
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Re[18]: Ключевое слово registr и указатель
От:
Аноним
Дата:
12.02.04 14:31
Оценка:
Здравствуйте, Faust, Вы писали:
F>>>// m = (n + k) + (n + k - g);
F>>>int m = ((n << 1) + (k << 1)) - g;
F>ты забыл про портируемость и про существование других компиляторов
Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха!
Про портируемость уж молчали бы...
P.S. Внимательно посмотрите на две формулы и подумайте про переполнение.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Faust, Вы писали:
А>
F>>>>// m = (n + k) + (n + k - g);
F>>>>int m = ((n << 1) + (k << 1)) - g;
А>
F>>ты забыл про портируемость и про существование других компиляторов
А>Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха!
завидный смех А>Про портируемость уж молчали бы...
у Вас есть доводы?... А>P.S. Внимательно посмотрите на две формулы и подумайте про переполнение.
при заданном пределе значений переполнения не будет.
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Re[20]: Ключевое слово registr и указатель
От:
Аноним
Дата:
12.02.04 15:14
Оценка:
Здравствуйте, Faust, Вы писали:
А>>Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха! F>завидный смех
Простите, не удержался. Вы очень смешной.
А>>P.S. Внимательно посмотрите на две формулы и подумайте про переполнение. F>при заданном пределе значений переполнения не будет.
Ну да, а при заданных значениях вычисления будут в compile time.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Faust, Вы писали:
А>>>Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха! F>>завидный смех
А>Простите, не удержался. Вы очень смешной.
А>>>P.S. Внимательно посмотрите на две формулы и подумайте про переполнение. F>>при заданном пределе значений переполнения не будет.
А>Ну да, а при заданных значениях вычисления будут в compile time.
подчеркиваю, не при заданных значениях, а при заданном(не превышающем) пределе значений. т.е обрабатываются не константные значения, а переменные
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
F>>ты забыл про портируемость и про существование других компиляторов
SM>наоборот, вполне возможен процессор (теоретически), в котором сдвиг работает медленее чем +
На современно уровне технологий -- нет (и теоретически и практически). Ну конечно, если специально задаться целью сделать гадость...
Здравствуйте, Андрей Галюзин, Вы писали:
F>> На компилятор надейся, но и сам не плошай
АГ>Лучше время потраченное на подобную оптимизацию посвящать развитию функциональности. АГ>А то получаются очень быстрые, но ничего не делающие приложения.
Очень быстрые, но не супер функциональные приложения(каждое под свой конкретный случай), лучше(ИМХО) супер тормозных и супер функциональных монстров, в которых для того чтобы провести несколько вычислений, нужно 15 минут ждать пока загрузится весь их, никак не относящийся к данной задаче, супер функционал.
// Мне намного приятнее, в том числе и с чисто эстетической точки зрения, написать
m = ((n + k) << 1) - g;
// вместо
m = (n + k) + (n + k - g);
, и преспокойно развивать функционал приложения, если он необходим
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
АГ>>Лучше время потраченное на подобную оптимизацию посвящать развитию функциональности. АГ>>А то получаются очень быстрые, но ничего не делающие приложения.
F> Очень быстрые, но не супер функциональные приложения(каждое под свой конкретный случай), F> лучше(ИМХО) супер тормозных и супер функциональных монстров, в которых для того чтобы F> провести несколько вычислений, нужно 15 минут ждать пока загрузится весь их, никак не F> относящийся к данной задаче, супер функционал.
Никто не мешает разбить приложение на модули (плагины) и подгружать их по мере необходимости.
Таким образом работает, например, Far и замечательно себя чувствует.
F>
F> // Мне намного приятнее, в том числе и с чисто эстетической точки зрения, написать
F> m = ((n + k) << 1) - g;
F> // вместо
F> m = (n + k) + (n + k - g);
F>
F> , и преспокойно развивать функционал приложения, если он необходим
Намного приятнее (и понятней, что немаловажно) написать
m = 2 * (n + k) - g;
А когда появятся реальные проблемы с производительностью, выраженные числами в профайлере, именно в этой функции (в чём я лично
сомневаюсь) переписывать её хоть на ассемблере.
