ламо о компиляторах

Поясни!

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

бред, раскутка делается для избежания переходов, очищающих кэш команд,

gcc позволяет это контролировать, некоторые из остальных нет, поэтому сравнение попахивает бредом.

Он правильно сказал. Расскрутка цикла возможна только в случаях когда что-то известно о числе итераций. Например, число итераций = 100 или число итераций кратно четырем. gcc нормально раскручивает только те циклы, где число итераций может быть точно определено на этапе компиляции. Понятно что в реальной проге число таких циклов невелико. Так ... удобный финт, но на практике особо не принципиален

>Он правильно сказал. Расскрутка цикла возможна только в случаях когда что-то >известно о числе итераций.

и где он правильно сказал? он имел ввиду что gcc смог вынести вычисления из цикла,
а unroll-loops к этому отношения не имеет.

это раз.

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

> и где он правильно сказал? он имел ввиду что gcc смог вынести вычисления из цикла, а unroll-loops к этому отношения не имеет.

Он сказал, что gcc развернул цикл и за счет этого удалось часть операций выполнить на этапе компиляции. Без разворота циклов это было бы нереально.

> повторять вычисления в цикле, причем с известным заранее числом итераций, и ограничивать только gcc от раскручивания цикла, это не тест на скорость вычислений, а тест на расрутку цикла, причем gcc зачем-то запретили это делать.

Он написал, что хотел провести тест в реальных условиях, а не на рафинированных примерчиках. В реальных условиях число итераций, как правило, неизвестно. Потому на тестовом примере разумно запретить разворачивать циклы. Другие компиляторы судя по всему раскрутку цикла не делали.

>Он сказал, что gcc развернул цикл и за счет этого удалось часть операций >выполнить на этапе компиляции.

и как вы это себе пресдтавляете?

for ()
f()

разворачивание цикла это
for ()
f()
f()
f()
f()

и как это помагает выполнить операции на этапе компиляции?

>Другие компиляторы судя по всему раскрутку цикла не делали.

я не особо смотрел какие там были компиляторы, но увидел icc,
если он не делает раскрутку цилка, то Билл Гейтс.

> Расскрутка цикла возможна только в случаях когда что-то известно о числе итераций. Например, число итераций = 100 или число итераций кратно четырем. gcc нормально раскручивает только те циклы, где число итераций может быть точно определено на этапе компиляции. Понятно что в реальной проге число таких циклов невелико. Так ... удобный финт, но на практике особо не принципиален

нет. Сложно раскрутить циклы в которых условие хитрое. А если просто N раз, то даже если N неизвестно при компиляции можно в рантайме поделить его на 4 или 8, а потом выполнить остаток число раз.

> и как вы это себе пресдтавляете?

for ()
f()

разворачивание цикла это
for ()
f()
f()
f()
f() 

Объясняю. Пусть имеем

unsgied int fact =1;

for (unsigned int i=fact_arg;i>1; i--)  fact *=i;

Предположим значение fact_arg нам известно, тогда можем лекго развернуть в 

fact =1;
i = fact_arg;

fact *=i;
i--;

fact *=i;
i--;

fact *=i;
i--;

... fact_arg -1 раз

fact *=i;
i--;

Далее, если вся исходная информация для этого кода также определена на этапе компиляции, т.е. имеем дело с детерминированной в терминах Дейкстры программой, то этот код лекго можно вычислить на этапе компиляции. т.е. если например fact_arg = 3 то получим

fact =1;
i = 3;

fact *= i; //1*3
i--; // 2

fact *= 2; // 1*3*2
i--; // 1

и заменть на 

fact = 6; 
i = 1;

> нет. Сложно раскрутить циклы в которых условие хитрое. А если просто N раз, то даже если N неизвестно при компиляции можно в рантайме поделить его на 4 или 8, а потом выполнить остаток число раз.

Согласен. Только gcc 2.95-3 врядли так делает.

Видимо потому, что в общем случае если есть цикл

for (i=0;i<count;i++) f();

то очень трудно на этапе компиляции определеить меняется ли count при выполнении тела цикла или нет.

Если f() не имеет прямого или косвенного доступа к count, ( например, count - обычная локальная переменная в блоке, содержащем цикл, а ссылки на нее никуда не передаются,) то, возможно, count не меняется до оканчания цикла.

> Если f() не имеет прямого или косвенного доступа к count, ( например, count - обычная локальная переменная в блоке, содержащем цикл, а ссылки на нее никуда не передаются,) то, возможно, count не меняется до оканчания цикла.

Вот именно, что возможно. К этой переменной легко можно перейти по стеку Редкий случай, но возможный.

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

> К этой переменной легко можно перейти по стеку Редкий случай, но возможный.

Он является ошибкой или хаком.

Если это хак - то такие переменные по СТАНДАРТУ надо объявлять, как volatile. Именно чтоб объяснить компилятору, что даже если он не видит, где её меняют, её всё равно могут в любой момент поменять.

Если какой придурок не объявляет volatile - то это его, придурка, половые трудности.

Ждем ответ Гентушников? Уж они-то точно знают что и как компилировать! :)

нет. это emerge знает:-) гентушники ждут ебилдов:-)