Re[2]: gcc?

[Konstantin Ovchinnikov <okl@ystu.yar.ru>]

Здравствуйте, Yuri.

Вы писали 12 июня 2003 г., 12:40:42:

YN> On Thu, 12 Jun 2003, Yury Yurevich wrote:

>> Hi, debian-russian!
>>
>> Господа, объясните мне, пожайлуста, объясните мне ситуацию с различными
>> версиями gcc.
>>
>> Итак, если есть проц (P4 или Athlon -- не важно, важно,  что в
>> march/mcpu для gcc-2.95 нет упоминания о них), значит ли это что, при
>> компиляции я максимум добиваюсь оптимизации для абстрактного i686?
>>
>> Есть научная программа, которае нечто считает; стОит ли
>> замарачиваться на вытягивание из сети gcc-3.2, даст ли это к-л
>> преимущества по сравнению с gcc 2.95/3.0.4 на athlon/p4?
>>
>> Теперь о компиляции ядра: почему его стоит собирать только с gcc-2.95?
>>
>> --
>> Best regards, Yury Yurevich
>>
>>
YN>  Hi,

YN>  По своему опыту работы с "научными программами" могу сказать,
YN>  что опции компилятора вообще, а опции относящиеся к процессору
YN>  в особенности, ничего не меняют (+/- 5% не в счет).
YN>  Ну не умеют еще компиляторы мысли отгадывать.
YN>  Если написано криво, и в цикле каждый раз вызывается никому не
YN>  нужная функция...
YN>  Часто подход к написанию, - главное что бы цифра вылезла,
YN>  а будет это день считаться или пять минут.., - значит
YN>  пора новую машину покупать. Общая кривизна кода близка
YN>  к абсолютной.

YN>  Правда, есть исключения в виде lapack, вернее blas, который
YN>  специально оптимизируют под отдельные процессоры. Но тут опять
YN>  скорее не компилятор важен, а нужную библиотеки надо найти.
YN>  (Это в сторону atlas надо смотреть)

YN>  С новым компилятором связываться стоит скорее не из-за
YN>  скорости, а потому как, все равно рано или позно, на него
YN>  перебираться прийдется. Плюс, к синтаксису (для с++)
YN>  он более строгий, - смотришь ошибки сами собой вылезут.

YN>  Удачи.
YN>  Юра.

Год-полтора назад ковырялся с опцией march в gcc 3.0 или 3.1 - сейчас
уже не помню. Машина - атлон, программа - amsol, если вам это ничего
не говорит - она проводит множество операций с матрицами и расчитывает
интегралы, т.е. чисто расчетная консольная прога.
Ускорение работы наблюдалось при переходе от march=386 к march=486 и к
march=athlon. 586 и 686 даже слегка замедляли расчет по сравнению с
486 8-))
Я уже не помню точно во сколько раз расчет ускорился (сравнивая
march=386 и march=athlon), примерно в 5-7 раз!!!!!!!
Можете представить мою радость - вместо 3-4 часов на задачу - 30 мин
(а бывают и более долгие задачки)
Да, забыл сказать - прога на фортране, компилировалась через
фортрановый транслятор в сишный код. Настоящими фортрановскими
компиляторами (в том числе и коммерческими) получался файл более
крупный и медленный.

Версии gcc не сравнивал, хотя собирался из спортивного интереса
перекомпилить на 3.2



-- 
С уважением,
 Konstantin                          mailto:okl@ystu.yar.ru