Re[2]: gcc?

[Yuri Nefedov <nefedov@nusun.jinr.ru>]

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:okl@ystu.yar.ru
>
>

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

 Да, конечно, универсальных рецептов не существует,
 наверное я несколько сгустил краски :)
 Хотя такой большой прирост производительности (5 раз)
 внушает подозрения, даже трудно придумать, за счет
 чего такое может быть. Я бы профайлером посмотрел,
 что изменилось. Все же, обычно, основное время,
 особенно если много расчетов с матрицами, съедается
 на fp-умножения, что тут выиграешь. Правда, возможно они
 (матрицы) в кеш стали умещаться, ну так это тоже не
 от компилятора зависит.
  Заг-г-гадочно...

 Успехов,
 Юра

 =============================================
 -- Вот дыры шире, шире, шире...
 -- А где же сыр?
 -- Забудь о сыре!
 =============================================