Да плевать как ты его видишь в ОС... То что ты его видишь как два проца не меняет одного факта - что в отличае от реального SMP, в HT некоторые блоки у этих якобы двух процов все-таки общие, отчего неизбежно будут возникать блокировки и прошу заметить - эти блокировки будут возникать в _других_ ситуациях, чем если бы это были два отдельных проца... Так вот - оптимизирующий компилятор обязан это учитывать, чтоб использование HT было максимально эффективным.

O, Irsi! Какими судьбами! Как там Windows рулит?:)

> Так вот - оптимизирующий компилятор обязан это учитывать, чтоб использование HT было максимально эффективным.

Вы мне примерчик, примерчик приведите. А то вот как мелкософт HT соптимизировал - это притча во всех языцах :))

Успокойтесь, компилятор icc бесплатный, да только как Саныч в native BSD Integrated Performance Primitives в без сырцов перетягивать будет я посмотрю.

Супер пример :))
void main( ) {
    int a[10000], b[10000], c[10000];
    int i,j;
    for( j=0; j<10000; j++)
    for (i=0; i<10000; i++) a[i] = a[i] + b[i] * c[i];
}

icc:
real    0m0.437s
user    0m0.580s
sys     0m0.150s

gcc:
real    0m0.564s
user    0m0.560s
sys     0m0.000s

Обратите внимание на sys !

Действительно, просто супер! Просто Hyper Threading!

А Вы тест некого широко известного в узких кругах господина Степанова прогоните, а потом и радуйтесь.

Хм, не образован, это какой?

Ну бля, бедный аноним со своими атлонами......

Вообщето можно возмутится, почему эт лялиховый гнусныйсик не компилит виндовые програмки... :)

Кстати, если поменять циклы местами, т.е.:
    for (i=0; i<10000; i++)
    for( j=0; j<10000; j++)
    a[i] = a[i] + b[i] * c[i];

то результаты совсем другие:

icc:
real    0m0.113s
user    0m0.090s
sys     0m0.000s

gcc:
real    0m0.483s
user    0m0.480s
sys     0m0.000s

Есть об чем подумать!

> лялиховый гнусныйсик не компилит виндовые програмки... :)

Во-первых, что такое "лялиховый"? Я не знаю такого слова.

Во-вторых, gcc для Windows существует уже очень давно.

В-третьих, Linux в отличие от *BSD и оффтопика поддерживает наиболее широкий спектр аппаратного обеспечения.

:)

>В-третьих, Linux в отличие от *BSD и оффтопика поддерживает наиболее широкий спектр аппаратного обеспечения.

А надувные пингвины еще летать могут :)

http://www.research.att.com/~orost/bench_plus_plus.html

А вот для духовного саморазвития

http://www.stlport.org/resources/StepanovUSA.html

STL не сама собой появилась. :)

Санычу, великому знатоку OpenMP

http://savannah.nongnu.org/projects/gomp/

>Linux в отличие от *BSD и оффтопика поддерживает наиболее широкий спектр аппаратного обеспечения.

Неужели??? В сравнении с NetBSD?

>>Linux в отличие от *BSD и оффтопика поддерживает наиболее широкий спектр аппаратного обеспечения.

>Неужели??? В сравнении с NetBSD?

Ну раз Саныч знаток мейнфреймов и особенно Hercules эмулятора, то *BSD рулит! :) Куда там нам, пингвиноводам.

Судя по вашим результатам у вас какой-нибудь Pentium III 800EB. Как там HT рУлит?:-))

:)

Ну и че?

Судя по наездам все считают, что это я написал компилятор для интела

и половину кода в FreeBSD kernel.

> Судя по вашим результатам у вас какой-нибудь Pentium III 800EB. Как там HT рУлит?:-))

Хм, ну Вы меня озадачили :)
cat /proc/cpuid:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.60GHz
stepping        : 9
cpu MHz         : 2612.604
cache size      : 512 KB
...
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.60GHz
stepping        : 9
cpu MHz         : 2612.604
...

Так что же, есть OpenMP для gcc или нет? А как там тест А.Cтепанова?

Ладно, на сегодня религиозных войн хватит. Вопрос в самом деле интересный

> и половину кода в FreeBSD kernel Почему 4.9 работает быстро, а 5.1 - хммм...?

> А как там тест А.Cтепанова?

Воюю. Скачал я его с указанных линок, победил зависимость от ksh, получил сообщение о том, что моя система Linux неизвестна, так что знакомлю :)

Waw!

У нас на PIII 800 такой же результат (icc 7.0, RH 7.2)! Слава Intel за хороший маркетинг в продвижении все более мощных и мощных процессоров и компиляторов для них. :)

-

2Irsi & ALL

насчет HT в числодробильне это полный fake (проверено электроникой ;))...

фокус в том что эти 2 "виртуальных проца" кормятся данными от одной шины - и в 90% случаев попытки "распараллелить" таким образом код приводят к perfomance downgrade

:)

Мне тут один дядя хитрый сказал, что HT есть только

на Xeon с большим кешем, а на P4 это типа фикция.

Может правда?

:)

Ну дык интел сам об этом писал, что fpu - это узкое место

>Если я уберу libcxa.so.3 будет ли у меня работать скомпилированная >интелом программа? ( вычисляющая sin(1), например).

Будет. Ключиков правильных в командной строке поставь, и усе будет. NikS чтоль вылез? Экзаменатор, ха :)

Нет, я не никс. Тот мерзкий тип, по-моему, наоборот, интел хвалил.

Во, блин, проверил у себя на Целероне, и офигел: P4: gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) gcc -O3 -ozg z.c time ./zg real 0m0.575s user 0m0.570s sys 0m0.000s

Celeron: gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) gcc -O3 -ozg z.c time ./zg real 0m0.129s user 0m0.100s sys 0m0.020s

И как это понимать? Все крыша поехала, пора ....

Это хорошо что успел "(почти)" написать. Никакой автоматики там и не предвидится (если вы не киборг).

Тестовый код

вот нарыл старый тестовый код
кому не лень могут потестировать ;)

--------------------------
/*
// TDMA
// to solve the system of equation:
// c[k]*x[k-1] + b[k]*x[k] + a[k]*x[k+1] = f[k],
// where c[1] = 0; a[n] = 0
*/
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <time.h>

double *be, *z; /* temporary arrays */

double TDMA(n, c, b, a, f, x)
int n; double *c, *b, *a, *f, *x;
{
   double d; int k;

   if( c[1] != 0.0 ) c[1] = 0.0;
   if( a[n] != 0.0 ) a[n] = 0.0;
   /* direct: */
      be[1] = -a[1]/b[1];
      z[1] = f[1]/b[1];
      for (k=2; k <= n; k++) {
         d = b[k] + c[k]*be[k-1];
         d = 1.0/d;
         be[k] = -a[k]*d;
         z[k]  = (f[k] - c[k]*z[k-1])*d;
      };
   /* come back:  */
      x[n] = z[n];
      for (k=n-1; k >= 1; k--)  x[k] = be[k]*x[k+1] + z[k];

   return 0.0;
};

int main() {

 double *c, *b, *a, *f, *x;
 int n=2000; /* A number of equations */
 int maxit=32000;  /* A number of TDMA calls */
 int i,it;
 clock_t start, end;

 c = (double*) calloc(n+2ouble*) calloc(n+2, sizeof(double));
 f = (double*) calloc(n+2, sizeof(double));
 x = (double*) calloc(n+2, sizeof(double));
 be = (double*) calloc(n+2, sizeof(double));
 z  = (double*) calloc(n+2, sizeof(double));
 
 for (i=0; i<n+2; i++) {
   c[i]=0.0; b[i]=0.0; a[i]=0.0; f[i]=0.0; x[i]=0.0;
 };
 for (i=2; i<=n-1; i++) {
   c[i]=0.5; a[i]=0.5; b[i]=-c[i]-a[i];
 };
 c[1]=0.0; a[1]=0.0; b[1]=1.0; f[1]=0.0;
 c[n]=0.0; a[n]=0.0; b[n]=1.0; f[n]=1.0;
 
 start = clock();
 for(it=0; it<maxit; it++) {
   TDMA(n, c, b, a, f, x);   /* Call TDMA maxit times*/
   for (i=2; i<=n-1; i++) {
     c[i]*= 1.0000001; a[i]*=1.0000002; /* Some corrections in coefs */
     b[i]=-c[i]-a[i];
   };
 };
 end = clock();
 printf(" Matrix Rang %d, N of TDMA Calls: %d\n", n, maxit);
 printf(" Total Time %f sec, Rate: %f TDMA calls / sec\n Solution:\n",
          (end-start)/((double)CLOCKS_PER_SEC), 1000*maxit/(((double)(end-start))));
 for (i=1; i<=4; i++) printf("x[%d] = %f\n", i, x[i]);
 for (i=n-3; i<=n; i++) printf("x[%d] = %f\n", i, x[i]);
 return 0;
}

>3. и про поддержку НТ в компиляторе -- ничего в этом крамольного нет и >бросаться словами "сами поняли чё сказали" не надо. НТ это не SMP и при >распараллеливании программы компилер должен это учитывать.

Нет в Intel компиляторах (равно как и в других) модулей распараллеливания программ - там есть костылики, могущие помочь при распараллеливании вами ваших программ. Но так как они hardcoded. То лучше вообще ими не пользоваться - потерь в вычислениях (даже при массовых качках памяти) не много, а гибкость перестройки программы на другую message-passing систему срежется начисто.

2sS: да я в курсе про то что HT не для числодробилок придуман - сам интель говорить что при активном юзанье FPU HT сосет и его надо отключать... Правда он тут же добавляет что в общем случае сосет fpu и есть более прогресивные технологие, такие как mmx, sse и их-то и надо использовать...:) Это интель сказал, не я...:) А имхо так х86 по жизни отсасывает в числодробилках и у рисков... И это еще никто не поборол. :)

Тяжкий вздох. Да, наверное. Некоторое время, пока разработчики не станут сильно зависить от фич интелловского компилятора. А потом интел раздумает давать свой компайлер просто так... Или прекратит его поддержку... И что тогда?.. Снова на gcc с __открытыми__ исходниками?

--koivu--

Ну сколько лет, сколько зим!

Кто тут меня проэкзаменовать решил?

icc -static my.C

А теперь мне можно вопрос задать?

Мерзкий тип

Тестовый код

>А имхо так х86 по жизни отсасывает в числодробилках и у рисков... И это еще никто не поборол. :)

Эти данные устарели с любого боку ;)

AMD покамест рулит в числодроблении на сегодняшний день

Интересно, что говорил он это в тот момент, когда RMS громче всего кричал о том, что Linux правильно назывть GNU/Linux.

--koivu--

" Auto-Parallelization: The Intel C++ Compiler 7.1 includes an Auto-parallelization feature for automatic threading of loops. This feature provides developers with an easy way to take advantage of parallelism to improve application performance on multiprocessor systems. This option detects parallel loops capable of being executed safely in parallel and automatically generates multithreaded code for these loops. Automatic parallelization relieves the user from having to deal with the low-level details of iteration partitioning, data sharing, thread scheduling and synchronizations. It also provides the benefit of the performance available from multiprocessor systems, and systems that support HyperThreading technology. " http://www.intel.com/software/products/compilers/clin/clinux.htm

anonymous (*) (11.11.2003 15:29:37)

Парни не краснеют - бизнес обязывает. Такая методика (с "ручной" поддержкой) еще худо-бедно работала на векторных процессорах. Про выделение инвариантов циклов - тоже лажа. Балансировки всей программы нет - поэтому говорить о крупноблочном Дейкстровском распараллеливании Intel-компиляторами тоже не имеет смысла. Насчет машинно-независимой оптимизации - издавна Portland Group компиляторы среди коммерческих наиболее продвинутые. Intel у них заказывал, например, для i860 процессоров - хорошо получилось - сам тескты компилятора смотрел. Сейчас показалось, что Intel их купил, или у них купил и за свой выдает - но нет Portland Group свои продает (сам хотел бы - начальство не спонсирует).

Когда же у менеджеров Intela (заметьте - "твидовых пиджаков", а не инженеров) спрашивали - заче им такая дезинформация - они отвечали в каком-то таком смысле "раз вы такие умные - то сидите и молчите"

to sS:
Запости еще раз свой код, как минимум не компилится (см. строку c = double*) cal... ). А если ее поправить, то coredump :(

to sS:

Ладно, сам разобрался :)

И на Celerone, и на P4HT icc немного уступает gcc. Приведу результаты только с P4:
icc -O3 -oyi -parallel -par_report3 y.c
   procedure: TDMA
   serial loop: line 24: not a parallel candidate due to insufficent work
   serial loop: line 32: not a parallel candidate due to insufficent work
   procedure: main
   serial loop: line 63: not a parallel candidate due to statement at line 64
   serial loop: line 74: not a parallel candidate due to statement at line 74
   serial loop: line 75: not a parallel candidate due to statement at line 75
   serial loop: line 53
      output data dependence assumed from line 54 to line 54, due to "x"
      output data dependence assumed from line 54 to line 54, due to "x"
      output data dependence assumed from line 54 to line 54, due to "x"
      output data dependence assumed from line 54 to line 54, due to "x"
y.c(56) : (col. 2) remark: LOOP WAS AUTO-PARALLELIZED.
   parallel loop: line 56
      shared: {"c", "b", "a"}
      private: {"i"}
      first private: { }
      reductions: { }
y.c(65) : (col. 4) remark: LOOP WAS AUTO-PARALLELIZED.
   parallel loop: line 65
      shared: {"c", "b", "a"}
      private: {"i"}
      first private: { }
      reductions: { }

./yi
 Matrix Rang 2000, N of TDMA Calls: 32000
 Total Time 3.260000 sec, Rate: 9.815951 TDMA calls / sec
...

gcc -O3 -oyg y.c
./yg
 Matrix Rang 2000, N of TDMA Calls: 32000
 Total Time 3.120000 sec, Rate: 10.256410 TDMA calls / sec
...

А тем временем

"афигедь Ну и на фига, к примеру, тому же самому ключастому gcc все эти маму их коромыслом sse2 с мымыхами? Опять пианэры висяляца...

Antichrist (*) (30.10.2003 15:53:36)"

http://www.linux.org.ru/profile/_white/view-message.jsp

:))))))))))))

AMD это тот же самый, убогий по жизни, х86. Как был он 32х разрядной надстройкой над 16ти разрядным расширением 8ми битного усовершенствоания 4х разрядного калькулятора, так и остался. А за х86-64 AMD вообще памятник поставить надо. И написать на нем "Плевать сюда"...
Чем быстрее здохнет убогий х86 во всех его проявлениях, тем всем лучше будет, однозначно...
Для справки - в числодробилках сегодня рулит PowerPC. В настоящих числодробилках, а не поделках красноглазых студентов. :)

> в числодробилках сегодня рулит PowerPC

Согласен.

> В настоящих числодробилках, а не поделках красноглазых студентов. :)

Так зачем же Вы сюда ходите? Я лично стал сюда ходить когда на Форуме снова появился главный "возмутитель спокойствия". :))) Прикольно после рабочего дня ;-)

Linux есть и для Power. У нас на работе - он третья Linux-платформа. Но и AIX + C for AIX мы не забываем.

http://www-3.ibm.com/software/awdtools/caix/

> PowerPC.

Вдогонку, POWER4, скорее! :-)

По-поводу AIX и PowerPC, ловите:
IBM RS6000 model F80, два проца

./ya
 Matrix Rang 2000, N of TDMA Calls: 32000
 Total Time 10.370000 sec, Rate: 3.085824 TDMA calls / sec

Какой компайлер? VA C++ 6.0?

Не, 5-ка + фикспаки. 6-ка пока в плане, есть проблемы.

Нормальная POWER начинается IMHO c pSeries 655.

Компайлер качните триал 6.0.

PS. Что то ушел наш великий сноб. А то встречный вопрос по VisualAge C++ для pLinux я ему подготовил. Как раз по omp-прагмам для цикла for.

IBM Thinkpad, PIII 500MHz, Windows XP:

Intel Compiler 7.1:
-------------------
> icl -O3 ya.c
...
> ya.exe
Matrix Rang 2000, N of TDMA Calls: 32000
Total Time 9.744000 sec, Rate: 3284.072250 TDMA calls / sec
...

Microsoft Visual C++ 6.0:
-------------------------
> cl -O2 ya.c
...
> ya.exe
Matrix Rang 2000, N of TDMA Calls: 32000
Total Time 10.805000 sec, Rate: 2961.591856 TDMA calls / sec
...

GCC 3.2.3 (mingw)
-----------------
> gcc -O3 ya.c
...
> ya.exe
Matrix Rang 2000, N of TDMA Calls: 32000
Total Time 10.965000 sec, Rate: 2918.376653 TDMA calls / sec

Каждый exe'шник запускал 3 раза и выбирал самый быстрый, чтобы
минимизировать эффект вмешательства системы.

> cl -O2 ya.c
Прошу прощения, ключики были:
cl /O2 ya.c
O2 - максимальный уровень оптимизации для майкрософтовского компилятора.

Математические рассчёты на кластерах

>По-поводу AIX и PowerPC, ловите: >IBM RS6000 model F80, два проца

>./ya > Matrix Rang 2000, N of TDMA Calls: 32000 > Total Time 10.370000 sec, Rate: 3.085824 TDMA calls / sec

а компилер OpenMP имеет ? а то ща перепишем под 2 проца ;)

BTW: кстати показательный результат на тему RISC vs современные x86 ;)

а если еще сравнить показатель ЦЕНА/производительность ...

Математические рассчёты на кластерах

Упс ... видать потер кусок при копировании ;)

собсно правка там тривиальная ;)


На домашнем Athlon-XP 1600+ (1400MHz)
результаты практически одинаковые для gcc 3.2.2 и icc5 (более свежих на домашнем компе нету)
-------------------------------

ss@xantippe:~/TDMA$ make gcc
gcc -I .. -I . -fomit-frame-pointer -O3 -ffast-math -mcpu=athlon-xp -march=athlon-xp -funroll-all-loops -fprefetch-loop-arrays -fmove-all-movables -freduce-all-givs -frerun-loop-opt -frerun-cse-after-loop -fschedule-insns2 -fstrength-reduce -fexpensive-optimizations -fcse-follow-jumps  -fcse-skip-blocks -malign-double -falign-loops=32 -falign-jumps=32 -falign-functions=32 -falign-labels=32 -msse -mfpmath=sse,387  -Wall -Wno-deprecated -W  -L /opt/intel/compiler50/ia32/lib -lcprts  tdma.c -o tdma-gcc
ss@xantippe:~/TDMA$ time tdma-gcc
 Matrix Rang 2000, N of TDMA Calls: 32000
 Total Time 3.430000 sec, Rate: 9.329446 TDMA calls / sec
 Solution:
x[1] = 0.000000
x[2] = 0.003200
x[3] = 0.006390
x[4] = 0.009570
x[1997] = 0.999984
x[1998] = 0.999989
x[1999] = 0.999995
x[2000] = 1.000000

real    0m3.483s
user    0m3.430s
sys     0m0.010s
ss@xantippe:~/TDMA$ make icc
icc -I /opt/intel/compiler50/ia32/include  -I /usr/include  -I /usr/local/include -I .. -I .    -O3  -rcd -xiMK -tpp6 -unroll1000000 -Zp16 -ip  -L /opt/intel/compiler50/ia32/lib -lcprts  tdma.c -o tdma-icc
tdma.c:
ss@xantippe:~/TDMA$ time tdma-icc
 Matrix Rang 2000, N of TDMA Calls: 32000
 Total Time 3.450000 sec, Rate: 9.275362 TDMA calls / sec
 Solution:
x[1] = 0.000000
x[2] = 0.003200
x[3] = 0.006390
x[4] = 0.009570
x[1997] = 0.999984
x[1998] = 0.999989
x[1999] = 0.999995
x[2000] = 1.000000

real    0m3.476s
user    0m3.440s
sys     0m0.020s