Ответ на »сообщение 6174« (Mirage)
___________________________

... На реальных задачах все куда грустнее, если, конечно, программист адекватен.
... ну и т.п. элементарные вещи.

А вот это хороший вопрос: идентифицировать (для реальных задач, конечно) мимимум простых и элементарных вещей, которые дают значимый выигрыш.

Ответ на »сообщение 6172« (Geniepro)
___________________________

Ответ на »сообщение 6169« (info21)
___________________________

>>> А он, кажись,  недешевый...

Линуксовая версия бесплатна...

Есть еще стоимость работы с этим монстриком.

Оптимизаторы, особенно от интеловского компилятора, умеют убирать целые выражения, которые не влияют на результат. В крайнем случае, убирают их из цикла. Особенно хорошо это им удается на синтетических тестах почему-то.:)
На реальных задачах все куда грустнее, если, конечно, программист адекватен.
Меня бы вполне устроил оптимизатор, умеющий использовать регистры, с которым не приходилось бы вводить доп. переменных, чтобы не вычислять выражения каждый раз (с Delphi приходится :( ), ну и т.п. элементарные вещи.

Ответ на »сообщение 6170« (AVC)
___________________________
>>> А он, кажись,  недешевый...

Линуксовая версия бесплатна...

_________________________


Я сегодня удивлялся, почему у меня на linnew XDS "побеждает" gcc с таким большим преимуществом (~800 MIPS против ~120). Потом обнаружил, что забыл скормить компилятору флаг оптимизации. Получилось ~800 против ~600. (Т.е. производительность в результате поднялась в 5 раз.) Так что всякое бывает.

А Вы попробуйте не GCC, а G++ -- он у меня на тесте Whetstone выдаёт почти 1900 MIPS против примерно 900 MIPS у GCC (Celeron 1.7). С максимальными оптимизациями в обоих случаях, конечно же...
XDS 2.51 (Linux Native) выдал 800 MIPS.

И ещё, недавно один фортер выяснил, что начиная с третьей версии GCC у него генерируемый код становился всё хуже и хуже. Версия 2.95 порождала в его тестах лучший код, затем версия 4.2, а промежуточные версии давали просто ужасный код с кучей лишних операций...
Я тестировал линуксовый G++ 4.1.3 против виндового GCC 3.4.2 (линуксовый G++ почему-то не находит функции sin, cos и т.д...). Надо бы проверить на VC2005 и BlackBox, да всё забываю...

Кстати, по поводу linnew. Вот результаты XDS:

LINPACK benchmark, Double precision.
Machine precision:  14 digits.
Array size  10 X  10.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
  16384  0.81  38.75%  21.25%  40.00%  9011.200
  32768  1.64  32.10%  19.14%  48.77% 10422.593
  65536  3.30  35.17%  21.71%  43.12%  9301.884
  131072  6.53  30.03%  21.83%  48.14% 10329.256
  262144  13.06  30.39%  21.27%  48.34% 10360.182
  524288  26.06  31.59%  22.79%  45.62%  9865.433

А вот у GCC:

LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 10 X 10.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
  65536  0.69  34.78%  21.74%  43.48%  44810.940
  131072  1.37  24.82%  23.36%  51.82%  52958.384
  262144  2.75  25.09%  24.36%  50.55%  51400.784
  524288  5.56  23.74%  23.92%  52.34%  52758.541

и G++:

LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 10 X 10.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
  65536  0.69  24.64%  23.19%  52.17%  52958.384
  131072  1.39  26.62%  22.30%  51.08%  51400.784
  262144  2.78  26.98%  26.26%  46.76%  47233.153
  524288  5.60  27.50%  25.18%  47.32%  47393.266
1048576  11.34  24.34%  22.93%  52.73%  52167.960

Пятикратное отставание XDS -- как Вам такое? :о))

Ответ на »сообщение 6169« (info21)
___________________________

>>> А он, кажись,  недешевый...

Линуксовая версия бесплатна...

Мое удивление вызвано не неверием в возможности оптимизации как таковые, а некоторой фантастичностью цифр (8000 MIPS), если их сопоставить, например, с частотой процессора.
Отсюда некоторое подозрение (такая форма гипотезы :) ), что компилятор "просёк", что какие-то вычисления не используются и соптимизировал их до нуля. Но это надо в коде разбираться...

Ответ на »сообщение 6165« (pepper)
___________________________

Интеловский компилятор оптимизирует плавающую точку. Но когда я это говорил, то меня упорно не хотели слушать :) Может конкретным циферкам поверите :)
Верить необязательно, раз можно проверить. :)
Вообще-то, конкретные "циферки" на отдельном тесте мало что говорят.
Надо проверять также на реальной задаче.
А так все измерения скачут. Вот на Вашей машине XDS обгоняет ББ более, чем в 2 раза, а на моей примерный паритет, причем даже чуть лучше у ББ.
Я сегодня удивлялся, почему у меня на linnew XDS "побеждает" gcc с таким большим преимуществом (~800 MIPS против ~120). Потом обнаружил, что забыл скормить компилятору флаг оптимизации. Получилось ~800 против ~600. (Т.е. производительность в результате поднялась в 5 раз.) Так что всякое бывает.
Но тема достаточно интересна, т.к. мне и самому порой приходится заниматься оптимизацией.

Ответ на »сообщение 6161« (AVC)
___________________________

Интересно, как Вы объясняете такой фактор?

Главное -- на 100% задействованы (FP) регистры и выброшены все обращения к памяти -- там латентность приличная.
Плюс перестановки операций, чтобы конвейер загрузить.

К сожалению, есть еще проблема контроля корректности вычислений -- ошибок округления и т.п.
А там будут через две операции стоять какие-нибудь глупости (типа принудить траекторию на границу и т.п.), которые не дадут компилятору оптимизировать.
Ну и так далее.
Пустое все это. Преходящее.

А стоит заложиться на интелевские компиляторы, так они начнут из этого доход извлекать: подкручивать нутро каждого нового процессора так, чтобы нужно было новую версию компилятора покупать. А он, кажись,  недешевый...

Ответ на »сообщение 6166« (pepper)
___________________________

делал далеко идущие выводы :)

Факт # вывод.

Ответ на »сообщение 6163« (RBV)
___________________________


8000? (да ещё так точно, по сравнению с предыдущими...)


Все очень просто. Квант времени в тесте - секунда, а ранится оно всего 5 секунд. На большее количество лупов тест не расчитан (там возникает целочисленное переполнение). Можете переписать тест для получения более точных результатов.


Помоему это бред.


Проверьте сами. Интеловский компилятор можно свободно скачать "на попробовать".


Такой результат никакая оптимизация не даст (ежели она на этот тест не заточена).


Никогда не говори никогда :) Такой же результат (оптимизация по скорости на порядок) на конкретном куске кода легко можно получить и на VC, если сравнить дебаговую сборку без оптимизации с релизной.


параметры у вашей машины?


Core 2 Duo.