Здравствуйте, Faust, Вы писали:
F>Привет!
F>1. Является ли указатель регистровой переменной? F>
F>//т.е, при объявлении
F>int* pArr = new int;
F>//процессор воспринимает pArr как регистровую переменную
F>
2. Верно ли, что при подобном выделении F>
F>register int* pArr = new register int[32];
F>
память выделится на стеке?
По умолчанию все локальные переменные — auto. И компилятор сам решает, будет ли переменная храниться в регистре или на стеке (оптимизация, наличие ссылок на данную переменную).
Память выражением new выделяется в куче, а не на стеке.
Компилятор должен выругаться на запись new register int, поскольку register — это спецификация переменной, и к типу никакого отношения не имеет.
Вообще, современные компиляторы болт забивают на auto|register.
Здравствуйте, Кодт, Вы писали:
К>По умолчанию все локальные переменные — auto. И компилятор сам решает, будет ли переменная храниться в регистре или на стеке (оптимизация, наличие ссылок на данную переменную). К>Вообще, современные компиляторы болт забивают на auto|register.
Хорошо. Как тогда современный компилятор(VC7) воспримет следующий код:
int& foo(int& integer)
{
integer += 100;
integer /= 10;
integer *= 10;
return integer++;
}
void main(void)
{
int integer = 1;
int result = foo(integer);
}
и во что он его оттранслирует в релизовом варианте?
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
К>Если компилятор инлайнит её — то всё может пройти и в регистре. А если нет — то извиняйте.
Другими словами, никаких гарантий у меня нет. И единственная возможность сделать именно то, что я хочу это использовать вставку __asm{ }
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
main()
{
int integer = 1; // скорее всего, в регистре
integer += 100;
integer /= 10;
integer *= 10;
++integer;
// в этом месте integer == 101, поэтому компилятор сделает простоint integer = 101;
int result = integer; // = 101
}
без инлайна
int* pfoo(int* v)
{
(*v) += 100;
(*v) /= 10;
(*v) *= 10;
++(*v);
return v;
}
main()
{
int integer = 1; // на стекеint* p = pfoo(&integer); // в регистреint result = *p;
}
К>>Если компилятор инлайнит её — то всё может пройти и в регистре. А если нет — то извиняйте. F>Другими словами, никаких гарантий у меня нет. И единственная возможность сделать именно то, что я хочу это использовать вставку __asm{ }
А что именно ты хочешь-то? Разместить на стеке блок произвольного размера?
Портабельного решения нет, однако у MS есть псевдофункция _alloca.
К регистрам это никакого отношения не имеет.
void foo()
{
char* buf = _alloca(count * sizeof(Type));
Type* vec = (Type*)buf;
placement_new(vec, vec+count); // конструируем объекты
// ищи по форуму - недавно было много обсуждений
.....
placement_delete(vec, vec+count); // деструируем объекты
// освобождать память вручную не надо - при выходе из блока всё произойдёт само
}
F>Другими словами, никаких гарантий у меня нет. И единственная возможность сделать именно то, что я хочу это использовать вставку __asm{ }
А что ты хочешь? Зачем управлять выделением автоматических переменных? С++ для этого в общем-то не предназначен, все эти ключевые слова типа regsiter — анахронизм.
int* pVal = new int;
//Всегда ли процессор воспринимает pVal как регистровую переменную
К>А что именно ты хочешь-то? Разместить на стеке блок произвольного размера?
Нет, мне нужна функция, которая проводит ряд простых вычислений, с тремя переменными, и возвращает результат. !!!НО!!!, эта функция может вызываться до 20000 — 30000 раз в цикле. Так вот, я пытаюсь выяснить, поможет ли мне использование регистровых переменных для ускорения процесса вычислении или нет.
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
F>Нет, мне нужна функция, которая проводит ряд простых вычислений, с тремя переменными, и возвращает результат. !!!НО!!!, эта функция может вызываться до 20000 — 30000 раз в цикле. Так вот, я пытаюсь выяснить, поможет ли мне использование регистровых переменных для ускорения процесса вычислении или нет.
нет не поможет, тк копилятор сам все сделает хорошо. И вообще, оптимизировать до измерений — зря терять свое время.
Здравствуйте, Faust, Вы писали:
F>Здравствуйте, Кодт, Вы писали:
F>Спасибо за объемный ответ. F>Еще раз переспрошу. F>
F>int* pVal = new int;
F>//Всегда ли процессор воспринимает pVal как регистровую переменную
F>
К>>А что именно ты хочешь-то? Разместить на стеке блок произвольного размера? F>Нет, мне нужна функция, которая проводит ряд простых вычислений, с тремя переменными, и возвращает результат. !!!НО!!!, эта функция может вызываться до 20000 — 30000 раз в цикле. Так вот, я пытаюсь выяснить, поможет ли мне использование регистровых переменных для ускорения процесса вычислении или нет.
Ну, тогда лучше на асме небольшую вставку сделать. Только тож с регистрами осторожно надо — вдруг какой-нить нужный запорешь.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
F>>Нет, мне нужна функция, которая проводит ряд простых вычислений, с тремя переменными, и возвращает результат. !!!НО!!!, эта функция может вызываться до 20000 — 30000 раз в цикле. Так вот, я пытаюсь выяснить, поможет ли мне использование регистровых переменных для ускорения процесса вычислении или нет.
SM>нет не поможет, тк копилятор сам все сделает хорошо. И вообще, оптимизировать до измерений — зря терять свое время.
Здесь, на форуме, у кого-то есть такая подпись — На компилятор надейся, но и сам не плошай
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Здравствуйте, Faust, Вы писали:
SM>>нет не поможет, тк копилятор сам все сделает хорошо. И вообще, оптимизировать до измерений — зря терять свое время. F>Здесь, на форуме, у кого-то есть такая подпись — На компилятор надейся, но и сам не плошай
Здравствуйте, Faust, Вы писали:
F>Здесь, на форуме, у кого-то есть такая подпись — На компилятор надейся, но и сам не плошай
Тут есть и другая подпись: "Premature optimization is the root of all evil in programming" (преждевременная оптимизация — корень зла в программировании). Тони Хоар, между прочим...
В общем, если будут тормоза — то смотри профайлером. Если не будут — забей болт.
Естественно, можно предусмотрительно избавиться от тупизмов, например, вычислений констант внутри цикла.
Отдавать предпочтение аналитическим вычислениям, затем итерационным, и только затем рекурсивным.
Использовать естественную для процессора арифметику (int и double) вместо явных short, float.
И т.п.
Здравствуйте, Кодт, Вы писали:
К>Тут есть и другая подпись: "Premature optimization is the root of all evil in programming" (преждевременная оптимизация — корень зла в программировании). Тони Хоар, между прочим...
абсолютно согласен
К>В общем, если будут тормоза — то смотри профайлером. Если не будут — забей болт.
К>Естественно, можно предусмотрительно избавиться от тупизмов, например, вычислений констант внутри цикла. К>Отдавать предпочтение аналитическим вычислениям, затем итерационным, и только затем рекурсивным. К>Использовать естественную для процессора арифметику (int и double) вместо явных short, float. К>И т.п.
в первую очередь оптимизировать алгоритм, а не программу
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Кодт, Вы писали:
К>>Тут есть и другая подпись: "Premature optimization is the root of all evil in programming" (преждевременная оптимизация — корень зла в программировании). Тони Хоар, между прочим...
SM>абсолютно согласен
К>>В общем, если будут тормоза — то смотри профайлером. Если не будут — забей болт.
SM> К>>Естественно, можно предусмотрительно избавиться от тупизмов, например, вычислений констант внутри цикла. К>>Отдавать предпочтение аналитическим вычислениям, затем итерационным, и только затем рекурсивным. К>>Использовать естественную для процессора арифметику (int и double) вместо явных short, float. К>>И т.п.
SM>в первую очередь оптимизировать алгоритм, а не программу
алгоритм сведен к простейшим арифметическим операциям и максимально(ИМХО) оптимизирован, как аналитически так и с точки зрения реализации. И данный вопрос возник именно при реализации конечного алгоритма. Т.к. хотелось максимально ускорить процес обмена данными между переменными.
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
SM>>в первую очередь оптимизировать алгоритм, а не программу F>алгоритм сведен к простейшим арифметическим операциям и максимально(ИМХО) оптимизирован, как аналитически так и с точки зрения реализации. И данный вопрос возник именно при реализации конечного алгоритма. Т.к. хотелось максимально ускорить процес обмена данными между переменными.
тогда надо ответить (прежде всего себе) не несколько вопросов:
1. сколько времени выполняется программа?
2. удовлетворяет ли Вас это время?
3. какая часть времени тратиться на данную ф-ию?
4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы
Здравствуйте, SergeMukhin, Вы писали:
SM>Здравствуйте, Faust, Вы писали:
SM>>>в первую очередь оптимизировать алгоритм, а не программу F>>алгоритм сведен к простейшим арифметическим операциям и максимально(ИМХО) оптимизирован, как аналитически так и с точки зрения реализации. И данный вопрос возник именно при реализации конечного алгоритма. Т.к. хотелось максимально ускорить процес обмена данными между переменными.
SM>тогда надо ответить (прежде всего себе) не несколько вопросов: SM>1. сколько времени выполняется программа?
фоновой режим SM>2. удовлетворяет ли Вас это время?
в данном случае(фоновой режим) вопрос некорректен SM>3. какая часть времени тратиться на данную ф-ию?
10000 вызовов укладывается в 70 мс SM>4. если эта ф-ия будет оптимизирована, повлияет ли это на качество программы
безусловно.
// глупо использовать следующий неоптимизированный кодint n = 3;
int k = 34;
int g = 765;
int m = (n + k) + (n + k - g);
// вместоint n = 3;
int k = 34;
int g = 765;
int m = ((n << 1) + (k << 1)) - g;
// даже если это не критический участок кода
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...