Здравствуйте, 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:[EMAIL PROTECTED]
