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

Ответ на »сообщение 6180« (Илья Ермаков)
___________________________

>>>Была выдвинута идея, что Intel так хорошо может оптимизировать, потому что только они знают, как CISC-команды отображаются в RISC ядра процессора:
http://forum.oberoncore.ru/viewtopic.php?p=11667#p11667

Даже если и так, то что? :) Это как-то умаляет достоинства интеловского компилятора?
Ни в коем случае!
Напротив, интеловский компилятор меня крайне заинтересовал.
Просто высказываем догадки, как это он так... :)
У меня для whetstone.c действительно космический результат (даже с печатью): 16000 и даже 20000 MIPS!

Правда, для linnew все не так фантастически, просто в рамках заурядного прогресса. :)

Intel C++

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

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    512  0.88  87.66%  0.00%  12.34%  916749.239
    1024  1.75  90.97%  0.91%  8.11%  874560.531
    2048  3.50  84.06%  5.80%  10.14%  894304.187
    4096  6.99  86.60%  4.74%  8.66%  881688.610
    8192  13.97  85.57%  3.26%  11.17%  906701.053
  16384  27.98  83.84%  3.37%  12.79%  921970.634
  32768  55.98  86.70%  2.58%  10.72%  900333.847

Соответствующие цифры для g++ и XDS я приводил в http://www.delphikingdom.com/asp/talktopic.asp?ID=368&ref=msg&msg=6178#msg6178

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


Эдак можно весь тест "убрать".
Наверное, эти 8000, озадачившие AVC, как раз из той оперы :-)

Кстати, если убрать вывод промежуточных результатов, то там вообще космические MIPS.

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


Очень любопытно было бы посмотреть на ассемблерный файл (как результат работы интеловского компилятора).

Файл на 80кб. Сюда постить не буду, могу выслать. Мои базовые знания ассемблера оказались бесполезны для понимания того, чего он там наоптимизил :)

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


Была выдвинута идея, что Intel так хорошо может оптимизировать, потому что только они знают, как CISC-команды отображаются в RISC ядра процессора:
http://forum.oberoncore.ru/viewtopic.php?p=11667#p11667


Вот результаты для моего домашнего AMD:
BB: 775.8
VC2005: 1111.1
Intel: 5555.6

Видимо интел и про АМД все знает ;)

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

Ответ на »сообщение 6180« (Илья Ермаков)
___________________________
Даже если и так, то что? :) Это как-то умаляет достоинства интеловского компилятора? Или хочется помечтать о несуществующих процессорах, на которых неоптимизирующий несуществующий компилятор BB не так бы злобно отставал? :)
:-)
Ну.. Ну например, хочется пожалеть о том, что все ПК работают на морально устаревших процессорах :-) Когда давно уже пора на что-то посовременней... С аппаратной типизацией, например, дабы сишники все переповесились :-))

Ответ на »сообщение 6180« (Илья Ермаков)
___________________________


Была выдвинута идея, что Intel так хорошо может оптимизировать, потому что только они знают, как CISC-команды отображаются в RISC ядра процессора:
http://forum.oberoncore.ru/viewtopic.php?p=11667#p11667

Даже если и так, то что? :) Это как-то умаляет достоинства интеловского компилятора? Или хочется помечтать о несуществующих процессорах, на которых неоптимизирующий несуществующий компилятор BB не так бы злобно отставал? :)

Ответ на »сообщение 6179« (pepper)
___________________________
Была выдвинута идея, что Intel так хорошо может оптимизировать, потому что только они знают, как CISC-команды отображаются в RISC ядра процессора:
http://forum.oberoncore.ru/viewtopic.php?p=11667#p11667

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


Эдак можно весь тест "убрать".
Наверное, эти 8000, озадачившие AVC, как раз из той оперы :-)

Весь тест нельзя убрать, потому что он там действительно что-то считает и результат зависит от количеста лупов.

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

Пятикратное отставание XDS -- как Вам такое? :о))
Это как-то связано с размером матрицы.
На большой матрице такого не наблюдается.
g++ и правда смотрится чуть лучше, чем gcc.

g++

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

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    256  0.61  79.47%  4.93%  15.60%  683994.812
    512  1.20  83.04%  2.66%  14.30%  682004.526
    1024  2.42  86.95%  1.94%  11.11%  653178.511
    2048  4.84  86.13%  3.86%  10.01%  645236.675
    4096  9.69  82.97%  3.36%  13.68%  672706.689
    8192  19.36  86.44%  2.51%  11.06%  653368.179
  16384  39.05  85.89%  2.96%  11.15%  648565.801
  32768  78.47  85.30%  2.54%  12.16%  652922.633

XDS

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

    Reps Time(s) DGEFA  DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    256  0.55  88.89%  0.00%  11.11% 725120.000
    512  1.11  77.27%  2.73%  20.00% 791040.000
    1024  2.20  76.15%  2.75%  21.10% 809436.279
    2048  4.41  79.86%  2.75%  17.39% 771318.781
    4096  8.81  73.51%  3.78%  22.71% 826249.496
    8192  17.73  78.01%  2.79%  19.20% 785461.439
  16384  35.42  76.90%  3.11%  19.99% 793859.102
  32768  70.80  75.65%  2.48%  21.87% 813575.106

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

Оптимизаторы, особенно от интеловского компилятора, умеют убирать ... выражения, которые не влияют на результат.

Эдак можно весь тест "убрать".
Наверное, эти 8000, озадачившие AVC, как раз из той оперы :-)