Кстати, метод прогонки - далеко не самый удачный пример для тестирования векторизующего компилятора - там же каждая итерация цикла жестко зависит от предыдущих. Да и деление в цикле жрет неслабо.

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

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

Открою страшный секрет ;) сейчас старые RISC-и выбрасывают на помойку а на их место профессора ставят именно "поделках красноглазых студентов" в виде x86+Linux - потому как основным показателем сейчас является такое понятие как "бюджет" а решний "под ключ" народ накушался по самые немогу - вон у меня толпа маков 92-93 года стоит сданных вместе со зданием. До сих пор списать никак не могут ;) такие тут местные правила ;) народ либо ходит на работу с ноутами либо притаскивает из дома свою технику для работы ;))) кстати сетка тоже делалась вместе со зданием (тонкий коаксиал вделана прямо в стены ;) и хрен поменяешь ;) (пока официальный срок эксплуатации не кончится ;))

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

Это поэтому японцы новый суперкомп на амд-шный 32-64 собирают, который будет вроде как самый мощный в мире?

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

И немедленно будешь ткнут носом в http://packages.debian.org/stable/devel/mingw32.html

Потому что компилит.

>Кто тут меня проэкзаменовать решил? icc -static my.C

Ну, крут :)) Правда, я ничего не спрашивал. Ну да ладно.

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

Нет. А про VA C++ -- тем более нет.

--- code_Ss_11.11.2003_17:52:16.orig Wed Nov 12 03:27:13 2003
+++ code_Ss_11.11.2003_17:52:16 Wed Nov 12 03:27:30 2003

@@ -42,7 +42,7 @@
int i,it;
clock_t start, end;

- c = (double*) calloc(n+2ouble*) calloc(n+2, sizeof(double));
+ c = (double*) 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));


testuser% cc code_Ss_11.11.2003_17:52:16.c

testuser% ./a.out
Ошибка адресации на шине (core dumped)
testuser% ./a.out
Ошибка адресации на шине (core dumped)

testuser% uname -srm
FreeBSD 5.1-CURRENT i386

testuser% gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.3.3 [FreeBSD] 20031106


вай? gcc кривой?:)

testuser% truss ./a.out
mmap(0x0,3560,0x3,0x1000,-1,0x0) = 1208397824 (0x4806b000)
munmap(0x4806b000,0xde8) = 0 (0x0)
__sysctl(0xbfbfe4a0,0x2,0x4806928c,0xbfbfe49c,0x0,0x0) = 0 (0x0)
mmap(0x0,32768,0x3,0x1002,-1,0x0) = 1208397824 (0x4806b000)
issetugid() = 0 (0x0)
open("/etc/libmap.conf",0x0,0666) ERR#2 'No such file or directory'
open("/var/run/ld-elf.so.hints",0x0,00) = 3 (0x3)
read(0x3,0xbfbfe538,0x80) = 128 (0x80)
lseek(3,0x80,0) = 128 (0x80)
read(0x3,0x4806f000,0x56) = 86 (0x56)
close(3) = 0 (0x0)
access("/lib/libc.so.5",0) = 0 (0x0)
open("/lib/libc.so.5",0x0,027757762620) = 3 (0x3)
fstat(3,0xbfbfe578) = 0 (0x0)
read(0x3,0x480681e0,0x1000) = 4096 (0x1000)
mmap(0x0,892928,0x5,0x20002,3,0x0) = 1208430592 (0x48073000)
mprotect(0x48135000,0x1000,0x7) = 0 (0x0)
mprotect(0x48135000,0x1000,0x5) = 0 (0x0)
mmap(0x48136000,20480,0x3,0x12,3,0xc2000) = 1209229312 (0x48136000)
mmap(0x4813b000,73728,0x3,0x1012,-1,0x0) = 1209249792 (0x4813b000)
close(3) = 0 (0x0)
mmap(0x0,144,0x3,0x1000,-1,0x0) = 1209323520 (0x4814d000)
munmap(0x4814d000,0x90) = 0 (0x0)
mprotect(0x48073000,0xc3000,0x7) = 0 (0x0)
mmap(0x0,21400,0x3,0x1000,-1,0x0) = 1209323520 (0x4814d000)
munmap(0x4814d000,0x5398) = 0 (0x0)
mprotect(0x48073000,0xc3000,0x5) = 0 (0x0)
sigaction(SIGILL,0xbfbfe5b8,0xbfbfe598) = 0 (0x0)
sigprocmask(0x1,0x0,0x4806813c) = 0 (0x0)
sigaction(SIGILL,0xbfbfe598,0x0) = 0 (0x0)
sigprocmask(0x1,0x480680e0,0xbfbfe5c8) = 0 (0x0)
sigprocmask(0x3,0x480680f0,0x0) = 0 (0x0)
readlink("/etc/malloc.conf",0xbfbfe560,63) ERR#2 'No such file or directory'
issetugid() = 0 (0x0)
issetugid() = 0 (0x0)
getuid() = 1001 (0x3e9)
getgid() = 1001 (0x3e9)
mmap(0x0,4096,0x3,0x1002,-1,0x0) = 1209323520 (0x4814d000)
break(0x804b000) = 0 (0x0)
break(0x804f000) = 0 (0x0)
break(0x8053000) = 0 (0x0)
break(0x8057000) = 0 (0x0)
break(0x805b000) = 0 (0x0)
break(0x805f000) = 0 (0x0)
SIGNAL 10
SIGNAL 10
Process stopped because of: 16
process exit, rval = 138
Ошибка адресации на шине (core dumped)

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

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

LOL
Sun-ch 100 баллов - это войдёт в историю :)))

Надувные пингвинятки ААААААААААААА - держите миня :))))))))))

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

>вай? gcc кривой?:) 


Держи _правильный_ патч ;)

--- tdma-bad.c	2003-11-12 08:15:38.000000000 +0300
+++ tdma.c	2003-11-12 08:15:33.000000000 +0300
@@ -42,7 +42,9 @@
  int i,it;
  clock_t start, end;
 
- c = (double*) calloc(n+2ouble*) calloc(n+2, sizeof(double));
+ c = (double*) calloc(n+2, sizeof(double));
+ b = (double*) calloc(n+2, sizeof(double));
+ a = (double*) 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));

>Так как там насчет int complex ?

И как там насчет char complex?

Тут важно не то, что именно icc собирается, а то, что не-gcc собирается. Мне кажется, это довольно существенный признак переносимости кода. Думаю, с Linux работы понадобилось бы существенно больше, чтобы собрать чем-то, отличным от gcc (хотя это, полагаю, возможно). И главное тут -- как можно больше локализовать код, зависимый от компилятора. Чтобы в перспективе можно было и Compaq C compiler собирать на альфах, и workshop'ом на спарках..

-- wart

а кто сказал что оно gcc собирается????? =)))

оно собирается unix cc

хехе ;]

2 sS:
Прикинь, а я _САМ_ сделал такой же патч!!! Это значит что я кульный хацкер! Ура!!! ;)))

Я сегодня в универе сравнивал качество оптимизации MS VC++ 6 (знаю что он старый, но новее под рукой не было) и MinGW (gcc-3.2.3) на том тесте, который прислал sS (спасибо!). Тестировалось на слабеньком втором пне.
В результате лучшее время (из 3-х запусков) показал код сгенерированный gcc - 23.13 сек. Код сгенерированный MS VC++ 6 выполнялся целых 32.41 с.

Тестовый код

>Прикинь, а я _САМ_ сделал такой же патч!!! Это значит что я кульный хацкер! Ура!!! ;)))

Ну если учесть что _обычно_ патчи делаются утилиткой diff то наверное кулхацкер ;)

Народ, а расскажите правду - в чем там вообще подноготная дела? Как следует из дискуссии, сторонники gcc пытаюстя уличить icc в каких-то мелких грехах - дык вопрос - зачем это нужно, какая цель? Разве плохо если будет два нормальных компилера?

Подобный казус здесь называется "членомерка".

Удивительно, что еще никто не рассказал, как gcc рвет всех так
тузик грелку на манфреймах :)

> Intel Compiler 7.1:
> -------------------
> > icl -O3 ya.c
> ...
> > ya.exe

Мда... первая мысль была - сборка яндексового робота :-)
Спать видимо пора идти :-)