On Thu, 12 Jun 2003, Konstantin Ovchinnikov wrote: > Здравствуйте, 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] > >
Здравствуйте, Konstantin. Да, конечно, универсальных рецептов не существует, наверное я несколько сгустил краски :) Хотя такой большой прирост производительности (5 раз) внушает подозрения, даже трудно придумать, за счет чего такое может быть. Я бы профайлером посмотрел, что изменилось. Все же, обычно, основное время, особенно если много расчетов с матрицами, съедается на fp-умножения, что тут выиграешь. Правда, возможно они (матрицы) в кеш стали умещаться, ну так это тоже не от компилятора зависит. Заг-г-гадочно... Успехов, Юра ============================================= -- Вот дыры шире, шире, шире... -- А где же сыр? -- Забудь о сыре! =============================================
