Обсуждение Intel с его "оптимизированными" библиотеками.
Версия для печати

Конференция: Конференция iXBT.com (http://forum.ixbt.com/)
Форум: Процессоры (http://forum.ixbt.com/?id=8)
URL: http://forum.ixbt.com/topic.cgi?id=8:13630

Время GMT +03. Даты в формате dd.mm.yyyy.


Serguei Kolossov, 30.12.2001 17:18
Итак по порядку.
Пишу я проги для расчета температур в 3D пространстве.
Мне необходимо использовать процедуры линейной алгебры.
Для этого существет библиотека LAPACK, весьма и весьма умная, но для тех у кого есть компилятор FORTRAN.
А у меня нет и решил я поиспользовать INTEL MathKernelLibrary (версия 5.1), что есть примерно то-же, но "оптимизированно" под INTEL-всевозможные процессоры и без надобности FORTRAN компилятора.
Ну вроде и работает и считает, но задумал я (после полугода работы с ней) проверить точность и скорость работы этой библиотеки.
К делу. Компилятор MS Visual C++ 6.0.
Есть операция суммирования всех элементов масива (вектора).
В BLAS (BasicLinearAlgebraSubprograms) она имеет название dasum (я работаю только с double переменными - первая буква). И я напияал свой метод :

double my_dasum(int &n,double *x)
{
double res=0;
for (int i=0;i<n;i++) res=res+x[i];
return res;
}

Вроде ничего сложного, но при испытании скоростей у процедур
1) cblas_dasum (производства Intel)
и
2) my_dasum (моего производства)
при обработке массивов длиной 10000 элементов,
время затраченное на выполнение 10000 операций 1) и 2) соответственно:
1) 1.001 сек
и
2) 0.301 сек.

Я был, мягко говоря удивлен.
Что это такое, если моя, написанная за пол минуты, процедура работает в 3!!! раза быстрее этой жутко умной INTEL - оптимизированной cblas_dasum.
Зачем тогда делать умный вид и говорить "А у нас есть специальные библиотеки для наших процессоров" (камень в огород INTEL).

Примечание (дабы избежать злобных ругательств со стороны защитников)
Протестированны все процедуры из 1 LEVEL BLAS, то есть вектор-вектор операций, и везде те-же результаты, кроме вычисления нормы вектора и домножения на число. Здесь я согласен они ее соптимизировали, у них в полтора раза быстрее.
Итого:
dasum 1.001 и 0.301
dcopy 1.422 и 0.530
ddot 1.012 и 0.380
dnrm2 1.261 и 0.370
dscal 0.030 и 0.121
dswap 5.137 и 0.761
Некоторые не приведены за ненадобностью.

P.S. И что уж говорить если некоторые процедуры обрабатывают массив, начиная с 1-го элемента, в не с нулевого.
P.P.S Я очень огорчен таким положением вещей.

Буду рад всем высказывающим свое мнение по этому поводу.
C НОВЫМ ГОДОМ!!!

1. IronPeter, 30.12.2001 17:56
Serguei Kolossov

Я в принципе уже Новый Год справляю, но мимо такого пройти не мог.

Не бывает такого! Единственное объяснение - p4+ SSE2+ данные с некратным 8 адресом. Потому как 100 Mflop на такой операции - позор. Может, еще массивы заполнены мусором...

2. Serguei Kolossov, 30.12.2001 18:12
Удачного справления!

А вот и не P4, а P3-1000.
Мусора нет, заполнаю или rand() или 1.0 везде.

double * x;x=new double[n];for (i=0;i<n;i++) x[i]=1.0;
double * y;y=new double[n];for (i=0;i<n;i++) y[i]=1.0;

Что скажете ?

3. Korzh, 01.01.2002 08:14
Serguei Kolossov
Ключевое слово -- double
И SSE и 3D Now! рассчитаны на single... так что в лучшем случае ты получишь ту же скорость... Ну а неудачный выбор алгоритма оптимизации приводит как раз к тому, что мы видим...

4. Hackerr2001, 01.01.2002 14:42
Serguei Kolossov
Кинь свою прогу(библиотеку) на мыло Dub01@mail.ru !!! Заранее спасибо!!!

5. IronPeter, 01.01.2002 17:58
Serguei Kolossov

Очень странные результаты - скажем, scale со скоростью 3000 MFLOP.
В такое я просто не могу поверить...

Интересно. Потратил некоторое время и написал свои процедуры. И, о ужас!

На dcopy я не мог выбраться из 1.5 секунд (а пробовал и MMX и строковые команды),
на ddot -1.25,
на dswap 2.5

При уменьшении длины вектора в 10 раз и увеличении числа шагов в 10 раз все ускоряется.
dcopy - ddot =0.17 (почти в десять раз быстрее!)
dswap = 0.5

Система Athlon 750+AMD 751.
И вопрос - неужели кеш у Атлона так плох!?

6. quest, 01.01.2002 18:14
Serguei Kolossov
for (int i=0;i<n;i++) res=res+x[i];

Для начала: dasum - не просто сумма элементов вектора, а сумма их абсолютных величин...

7. Serguei Kolossov, 01.01.2002 18:45
2 Korzh
Да я вовсе не говорю, что на AMD обязательно будет быстрее, нет...
Я просто имею ввиду, что довод "А у INTEL есть оптимизированные математические библиотеки" не есть актуален, поскольку не работает, хотя звучит действительно сильно. И у AMD поддержка вовсе не хуже, в этом контексте.

Hackerr2001
Сейчас скину.

quest
Согласен, исправлюсь, но на остальные процедуры это не влияет.

8. quest, 01.01.2002 19:03
Serguei Kolossov
на остальные процедуры это не влияет

Сие трэба разжуваты

Вы реализовали те же самые процедуры?
В частности: инкременты задействовали? Поясняю: в той же dasum не 2 параметра, а три - третьим параметром является инкремент элементов вектора (может быть и отрицательным). Инкременты весьма влияют на скорость работы, особливо если они нечетные и не равны 1...

Учтите, что эти функции оптимизированны под решение задач линейной алгебры, а не сами по себе. Посему, инкременты играют значительную роль.

Dcopy без инкремента вообще большого смысла не имеет, т.к. пересылку плотного массива на другое место можно сотворить c помощью memcpy и, скорее всего, это будет быстрее всего...

9. Serguei Kolossov, 01.01.2002 19:17
quest
Это все более более, чем верно.
Я проверял все инкременты, имеется ввиду -1 , 0 , 1.
В некоторых процедурах 2 инкремента, в некоторых 1.
НО все результаты с инкркментами кроме (-1,-1) или (1,1) НЕПРАВИЛЬНЫЕ - это для процедур с двумя.
Будут еще идеи - пиши.

10. quest, 01.01.2002 19:22
Serguei Kolossov

А что означает: все результаты НЕПРАВИЛЬНЫЕ?

Что-что, а неправильных результатов в MKL пока не замечено

И вообще: проще будет прислать мне тестовый исходник - я покажу, где что не так

11. Serguei Kolossov, 01.01.2002 19:33
quest

Куда слать то ?

12. quest, 01.01.2002 19:33
Serguei Kolossov
Через сервер, ессно

16. quest, 01.01.2002 19:59
Serguei Kolossov
Вроде отослал.

ОК! Получил. Если нет возражений, то своё заключение дам завтра вечером (счас уже поздновато работать для 1-го января). Если возражения есть, то всё-равно - завтра...

17. Serguei Kolossov, 01.01.2002 20:05
quest
Конечно нет никаких возражений.
Желаю удачного и главное плодотворного отдыха.
Жду ответов и идей.

18. Hackerr2001, 01.01.2002 20:14
Serguei Kolossov
Пожалуйста кинь на мыло dub01@mail.ru !!!!!

19. IronPeter, 01.01.2002 20:17
По поводу dcopy - я как не реализовывал (MMX, memcopy) - все едино. По поводу инкрементов - ну так должен быть переключатель, который для разных значений инкремента запускает разные ветви алгоритма. Так что вопрос остается.

Интересно, что приведеные результаты MKL очень близки с тем, что я получал на аналогичных тестах (но на Атлоне). За исключением scale, который ошибочный. А вот результаты руками написанных функций - ну не в какие ворота... Может, выложишь(те) на ftp С код?

20. Serguei Kolossov, 01.01.2002 21:59
Hackerr2001
Да я уже несколько часов как отослал, причем с mail.ru на твой адрес.
IronPeter
У меня сдесь с ftp туго, но могу на мыло скинуть, они (файлы) маленькие.
Если это подойдет, то напиши тут, я online пока до 11 вечера.

25. Hackerr2001, 02.01.2002 00:51
Serguei Kolossov
Всё!!! Получил!!! Спасибо ещё раз!!!

26. Chudik, 02.01.2002 10:43
Народ, я тут потёр немного вашу переписку по поводу того. что и куда слать. Не обессудьте

А тема интересная... Только, может, в программирование её,а?

27. Hackerr2001, 02.01.2002 16:51
Chudik
Не!!! Вся таки речь идёт о процессоре и его логики!!!

Serguei Kolossov
Вот мои результаты:
10000 Operation <dasum> Intel -> 0.701s
10000 Operation <dasum> home -> 0.291s
10000 Operation <dcopy> Intel -> 1.482s
10000 Operation <dcopy> home -> 0.491s
10000 Operation <ddot> Intel -> 1.953s
10000 Operation <ddot> home -> 0.371s
10000 Operation <dnrm2> Intel -> 0.250s
10000 Operation <dnrm2> home -> 0.361s
10000 Operation <dscal> Intel -> 0.030s
10000 Operation <dscal> home -> 0.110s
10000 Operation <dswap> Intel -> 5.147s

РУЛЛЕЗЗЗ!!!, вот только в последних случаях немного проигрывает, ещёб немного доделать и усё!!! А вообще не плохо!!! Может кинеш на мыло Dub01@mail.ru свои библиотеки?

28. quest, 02.01.2002 17:10
Serguei Kolossov

Посмотрел слегка

Несколько замечаний по тесту:

1. Замер скорострельности таймером не даёт на таких быстрых задачах нормального результата. Советую пользоваться (на P3) следующей фичей:

код:

typedef struct {
unsigned long int l; /* bits 0-31 */
unsigned long int h; /* bits 31-63 */
} ulonglong_t;

double rdtsc_()
{
double bignum = 4294967296.0;
double temp;
ulonglong_t tsc;
void rdtsc();

rdtsc( &tsc );
temp = (double)tsc.h * bignum;
temp += (double)tsc.l;
return( temp );
}

void rdtsc(ulonglong_t *p)
{
_asm {
_emit 0x0f /* rdtsc */
_emit 0x31

mov ecx,p
mov dword ptr [ecx],eax /* save low 32 bits */
mov dword ptr [ecx+4],edx /* save high 32 bits */
}
}



После вызовов:
код:

t1=rdtsc_();
...timing function...
t2=rdtsc_();


t2-t1 даст время исполнения таймируемой функции в тактах процессора.

2. "Замедление" работы функции путем её вызова в цикле много раз подряд с одними и теми же параметрами искажает результаты, т.к. после первого вызова данные будут в кеше (кешах). Кроме того, возможна глобальная оптимизация кода. Перед таймированием необходимо "выталкивать" из кешей всех уровней используемые данные. Если нужно таймировать в "горячем" кеше, тогда перед вызовом нужно данные в кеш поместить.

3. Я замерил (в тактах на один элемент вектора) на P3 (coopermine 700Mгц). Компиллер - Интел С/C++, MKL v. 5.2. Результат:
код:


dasum
size repeat my mkl
10 104857 28.267081 26.885646
20 52428 21.905982 16.273011
50 20971 18.130626 12.282617
75 13981 16.494677 10.932563
100 10485 15.950215 9.271766
200 5242 15.292849 8.550806
500 2097 13.830608 7.942229
750 1398 13.539414 8.099615
1000 1048 13.570001 7.835414
2000 524 13.467366 7.808948
5000 209 13.371389 7.717327
7500 139 13.450998 7.708463
10000 104 13.372976 7.643865
20000 52 13.372024 7.606988
50000 20 13.394078 7.619859
75000 13 13.433795 7.604959
100000 10 13.396443 7.596096
200000 5 13.597793 7.604259
500000 2 13.537855 7.673929
1000000 1 13.369119 7.609528

dcopy
size repeat my mkl
10 104857 54.051870 36.825274
20 52428 39.677068 36.830369
50 20971 43.980149 34.498046
75 13981 45.308873 34.142075
100 10485 46.317728 31.228986
200 5242 47.638859 30.208696
500 2097 48.229654 29.221970
750 1398 42.494126 31.829604
1000 1048 44.163977 30.981020
2000 524 42.023199 31.517648
5000 209 41.307103 31.532905
7500 139 40.911276 31.773464
10000 104 40.281615 32.625367
20000 52 40.781258 31.742436
50000 20 42.314053 30.578113
75000 13 42.906417 31.298749
100000 10 45.344656 28.642135
200000 5 48.220381 26.860728
500000 2 49.115833 26.807934
1000000 1 49.862337 28.645463

ddot
size repeat my mkl
10 104857 42.863062 38.328876
20 52428 35.274415 26.192289
50 20971 29.734568 22.017926
75 13981 27.274887 21.439268
100 10485 26.137124 20.256649
200 5242 24.855961 19.453513
500 2097 23.836744 18.982531
750 1398 23.531456 19.488573
1000 1048 23.511002 19.434332
2000 524 23.543773 19.068542
5000 209 23.424579 18.809541
7500 139 23.149689 18.755081
10000 104 23.357181 18.795111
20000 52 23.485986 18.727698
50000 20 23.285320 18.795939
75000 13 23.393065 18.723777
100000 10 23.255325 18.849855
200000 5 23.306389 18.661346
500000 2 23.275705 18.681371
1000000 1 23.267900 18.681466

dnrm2
size repeat my mkl
10 104857 32.824648 42.717723
20 52428 25.666255 30.181570
50 20971 21.450026 19.593558
75 13981 19.838131 18.752376
100 10485 19.064987 17.305961
200 5242 17.665778 15.043747
500 2097 17.059804 14.445719
750 1398 16.905403 13.715969
1000 1048 16.925969 13.995700
2000 524 16.685359 13.698105
5000 209 16.565359 13.528241
7500 139 16.520130 13.515548
10000 104 16.812512 13.501459
20000 52 16.739170 13.363550
50000 20 16.784596 13.279796
75000 13 16.839572 13.212026
100000 10 16.900123 13.181992
200000 5 16.845680 13.398600
500000 2 17.008406 13.148299
1000000 1 16.849626 13.184145

dscal
size repeat my mkl
10 104857 50.021941 50.823260
20 52428 51.598066 29.355007
50 20971 46.437302 29.501054
75 13981 43.640347 29.467946
100 10485 45.542059 26.058099
200 5242 43.403620 26.394187
500 2097 41.867411 26.244656
750 1398 50.377195 18.695121
1000 1048 42.785823 25.235616
2000 524 57.889778 12.280716
5000 209 48.040090 20.374963
7500 139 45.273718 22.907507
10000 104 44.324864 23.611369
20000 52 42.553149 24.930208
50000 20 41.399655 25.934931
75000 13 41.492994 26.009756
100000 10 41.058539 26.250869
200000 5 40.988150 26.390247
500000 2 40.937155 26.190132
1000000 1 41.108669 26.183729

dswap
size repeat my mkl
10 104857 103.771248 54.094010
20 52428 96.412897 56.988521
50 20971 98.280820 50.407669
75 13981 95.028604 54.564187
100 10485 91.938503 55.131956
200 5242 90.738692 54.742711
500 2097 89.589802 55.899514
750 1398 112.060318 36.827278
1000 1048 125.180655 24.977448
2000 524 104.765238 41.072508
5000 209 91.634531 52.451971
7500 139 88.701663 54.339594
10000 104 87.130005 55.929963
20000 52 84.667981 58.343439
50000 20 83.273652 59.836810
75000 13 83.332222 59.272225
100000 10 83.074741 59.335830
200000 5 83.204032 59.475248
500000 2 82.907927 59.449042
1000000 1 82.999994 59.347186



Разница есть?

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


dasum
size repeat my mkl
10 419430 14.066805 20.944974
20 209715 25.119710 10.205989
50 83886 8.630718 8.629482
75 55924 5.471189 5.905560
100 41943 6.322258 5.211443
200 20971 4.376607 3.728145
500 8388 3.649969 2.770477
750 5592 3.561394 2.640986
1000 4194 3.514258 2.602052
2000 2097 3.420499 2.354125
5000 838 4.281472 2.941522
7500 559 5.414812 3.189330
10000 419 6.884828 3.511162
20000 209 13.452598 4.784739
50000 83 17.496400 6.552770
75000 55 16.096496 6.925593
100000 41 15.316787 7.075424
200000 20 13.900080 7.288528
500000 8 13.218573 7.435763
1000000 4 12.870491 7.493566

dcopy
size repeat my mkl
10 419430 26.880824 17.166041
20 209715 15.755154 9.186872
50 83886 5.232140 4.723080
75 55924 3.678436 3.771808
100 41943 3.858535 3.057441
200 20971 2.668597 2.336412
500 8388 2.213999 1.905853
750 5592 2.179272 2.314004
1000 4194 2.047947 2.236630
2000 2097 3.969075 12.109729
5000 838 5.500026 18.270928
7500 559 6.895991 19.306005
10000 419 8.745315 19.694248
20000 209 22.090097 22.166251
50000 83 40.064458 26.146556
75000 55 43.016342 25.544060
100000 41 44.260258 25.093776
200000 20 45.771996 24.446225
500000 8 46.294231 23.990015
1000000 4 46.467534 22.319727

ddot
size repeat my mkl
10 419430 34.849559 21.992838
20 209715 12.407951 25.530499
50 83886 9.303634 8.032512
75 55924 6.895151 5.651797
100 41943 5.989984 7.538144
200 20971 5.020277 4.877694
500 8388 4.059385 3.838799
750 5592 4.101182 3.589467
1000 4194 3.980637 3.676312
2000 2097 4.952971 4.742898
5000 838 6.986635 4.881255
7500 559 9.892495 5.259744
10000 419 13.150736 5.755530
20000 209 25.532235 7.988981
50000 83 32.187540 12.438037
75000 55 29.668400 13.519264
100000 41 27.123200 13.925836
200000 20 23.293061 14.628034
500000 8 21.060111 15.125507
1000000 4 20.249075 15.172180

dnrm2
size repeat my mkl
10 419430 13.864547 28.845500
20 209715 25.214974 23.420721
50 83886 8.319343 8.577759
75 55924 7.124564 6.626026
100 41943 7.135860 5.461488
200 20971 5.252262 4.406497
500 8388 4.163359 3.264428
750 5592 3.917518 3.011150
1000 4194 3.841504 2.963343
2000 2097 3.772478 2.786998
5000 838 4.355001 3.564365
7500 559 5.608857 4.673784
10000 419 7.359142 6.223489
20000 209 14.880262 12.754933
50000 83 20.108202 17.204246
75000 55 18.803142 16.089777
100000 41 18.102095 15.378474
200000 20 17.124966 14.261383
500000 8 16.614844 13.604887
1000000 4 16.309778 13.414222

dscal
size repeat my mkl
10 419430 20.400659 21.984301
20 209715 20.896855 17.987550
50 83886 7.991373 9.142299
75 55924 6.227672 5.840621
100 41943 6.304387 5.509069
200 20971 4.069761 3.738409
500 8388 3.006773 2.707948
750 5592 2.866211 2.501709
1000 4194 2.737752 2.391508
2000 2097 2.657851 2.264118
5000 838 3.624668 3.231688
7500 559 4.783912 4.010023
10000 419 6.314613 4.902742
20000 209 15.912406 9.817145
50000 83 28.474133 18.865449
75000 55 31.716826 21.236253
100000 41 33.172571 22.548657
200000 20 35.590167 24.575411
500000 8 36.967416 25.621231
1000000 4 37.417562 25.942575

dswap
size repeat my mkl
10 419430 27.281526 18.142895
20 209715 13.939309 14.448024
50 83886 9.352785 9.955220
75 55924 7.896334 6.142669
100 41943 6.671032 5.648298
200 20971 6.038646 5.121799
500 8388 5.456956 3.995233
750 5592 5.344580 4.029378
1000 4194 5.281793 4.126387
2000 2097 5.756830 5.072819
5000 838 8.384508 6.084923
7500 559 11.470731 6.965769
10000 419 15.016261 8.450623
20000 209 36.032101 17.942218
50000 83 65.142664 38.048569
75000 55 72.083752 43.538018
100000 41 75.501739 46.357784
200000 20 80.908164 50.728012
500000 8 84.069200 53.250070
1000000 4 84.965613 54.112335

Интересно?

29. Serguei Kolossov, 02.01.2002 20:06
Hackerr2001

Да вообще-то я не делал библиотек еще, а код что ты использовал есть в файле, что я тебе скинул, все в нем.
Но видимо господин quest развеял некоторые вопросы, но надо думать над этим еще.
Я извиняюсь, но получил:


This message was created automatically by mail delivery software.

A message that you sent has not yet been delivered to one or more of its
recipients after more than 12 hours on the queue on f3.mail.ru.

The message identifier is: 16LRWL-0005Kc-00
The subject of the message is: SpeedTest
The date of the message is: Tue, 01 Jan 2002 19:12:09 +0300

The address to which the message has not yet been delivered is:

Dub01@mail.ru
unknown error

No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.

Это на мэйл, так что не знаю что и делать, может еще куда можно файлы сбросить ?


quest
Более чем интересно.
Но есть некоторые вопросы:
вопервых почему такие странные результаты с кодом, что я написал ?
вовторых и в ваших тестах INTEL библиотеки далеко не всегда быстрее - почему ?


Chudik

Я в принципе не против (а могу ли я быть против) помещения этой ветки в програмирование, но надо другим участникам сообщить.

Ты автор темы, тебе в данном случае и решать, где лучше видеть эту тему. В данном случае я просто предположил место, где может быть больше ответов. Просто тема на границе одного и другого.
Единственная просьба - почистить потом за собой разговоры на тему адресов пересылки, чтобы не загромождать основной топик.

30. Hackerr2001, 02.01.2002 21:24
Serguei Kolossov
Можно!!! На Dub01@UkrTOP.com !!!

31. bess, 03.01.2002 16:29
Serguei Kolossov
Chudik

IMHO тема все же ближе к процессорам, поскольку методы и приемы напрямую связаны с архитектурными особенностями CPU (и систем в целом). К программированию относится лишь обсуждение качества трансляторов

ok

32. quest, 03.01.2002 16:54
Serguei Kolossov
вопервых почему такие странные результаты с кодом, что я написал ?

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

вовторых и в ваших тестах INTEL библиотеки далеко не всегда быстрее - почему ?

На "холодном" кеше "далеко не всегда" - это только dnrm2 и только при малой длине вектора (10-20). Легко объясняется бОльшими накладными расходами на вызов функции и начальное ветвление по типам инкремента (ваша функция инкремента - значит его анализа и соответсвующего ветвления - не имеет).

Что до "горячего" кеша, то тут всё настолько тонко, что имеет смысл смотреть всё это только "в среднем". Ну а в среднем MKL бьёт простые реализации везде.

Лично меня только слегка удивили результаты dcopy на длинах от 2000 до 10000. Но только слегка - значениям на "горячем" кеше стоит доверять только в том случае, если "убиты" все процессы в системе и ничто постороннее на тест не влияет. Я тестировал на своем рабочем компе, ничего не убивая и специально не готовя. И нет никакой гарантии, что был замерен именно случай "горячего" кеша.

33. FunRoger, 04.01.2002 08:50
questЭх, молодость, молодость...

void rdtsc(__int64 *iValue)
{
__asm
{
rdtsc;
mov edi, iValue;
mov [edi], eax;
mov [edi + 0x04], edx;
}
};

так же короче ?

34. quest, 04.01.2002 12:14
FunRoger
так же короче ?

Я еще лет двадцать назад перестал гнаться за "короткостью" прог в пользу понятности и читабельности...

И ни разу не пришлось об этом пожалеть!

Ближе к телу: у All еще есть сомнения насчет качества оптимизированности MKL, или уже всё ясно?

35. Const, 04.01.2002 15:22
quest
ты часом не в Интеле работаешь?
Уж больно все профессионально разжевал...

36. quest, 04.01.2002 15:35
Const
ты часом не в Интеле работаешь?

Я ж не из Нижнего - енто у вас там филиал Интела. А я - километров на 200 южнее. Но, - почти...

37. Const, 04.01.2002 15:42
Ясненько...

38. bess, 04.01.2002 16:31
quest

> Ближе к телу: у All еще есть сомнения насчет качества оптимизированности MKL, или уже всё ясно?

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

39. IronPeter, 04.01.2002 21:34

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

Кстати, откомпилированный пример с MKL запустился на моем Атлоне, показав преимущество интеловской оптимизации. В разы. Результаты прямо противоположные представленным докладчиком. И очень близкие к моим
результатм ручной оптимизации.

40. quest, 05.01.2002 12:39
IronPeter
Но общественности непонятно: почему в данном конкретном примере собственная ручная реализация выигрывает у интеловской в разы.

А где он, этот самый конкретный и замечательный пример представлен?

Если Вы о первоначальных данных автора ветки, то что там меряно и чем? С таким же успехом можно померять время движения трамвая "А" от Котельнической набережной до Патриаршьих прудов. Апосля чего, делать выводы об оптимизации транпортного потока на МКАД...

Я вижу единственное объяснение: MKL как-то взаимодействует со стандартным
таймером, так что результаты работы хронометрируются неправильно.

Смею Вас уверить, что MKL никак с таймером не взаимодействует. Более того - хидера Timer.h (и соответствующей библиотеки) в стандартном ANSI-C (бОльшая часть кода МКL на нём написана) и интеловском компиллере С просто нет.
А результаты действительно хронометрируются неправильно - я об этом писал уже не раз. Портновским метром затруднительно измерять (и тем более - сравнивать) микронные объекты.

Кстати, откомпилированный пример с MKL запустился на моем Атлоне, показав преимущество интеловской оптимизации. В разы. Результаты прямо противоположные представленным докладчиком. И очень близкие к моим
результатм ручной оптимизации.

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

41. IronPeter, 05.01.2002 13:04
quest

Хорошо. Я использовал exe файл автора ветки, каковой файл входит в комплект рассылки. Погрешность измерения виндового таймера в пределах сотых долей секунды. Между тем результаты различаются на секунды и в разы. На Intel системах ручная реализация быстрее MKL, на моем Атлоне наоборот. И опять в разы и на секунды.

Микронные объекты вполне реально измерять портновским метром. Ежели их приложить друг к другу в известном количестве. И ежели портновский метр обеспечиывает нужную точность. Виндовый таймер обеспечивает.

Мое предложение по поводу взаимодействия MKL и таймера конечно бредовое. Но как иначе объяснить _секунды_ разницы? С трудом я могу поверить в то, что MKL, обращаясь к сервисам операционной системы, как-то влияет на таймер (который тоже сервис win). Но это все, что у меня есть...

Так что я могу предложить переписать код и использованием точного хронометрирования. И поменяв порядок исполнения MKL и ручных процедур (для нейтрализации кеша). Ежели результаты останутся в силе, то это будет необъяснимо...

42. quest, 05.01.2002 13:45
IronPeter
И поменяв порядок исполнения MKL и ручных процедур (для нейтрализации кеша).

Да не будет никакой нейтрализации кеша! Ибо в тесте Serguei Kolossov просто много раз повторяет один и тот же вызов с одними и теми же данными! Получается смесь какая-то, которая не имеет отношения ни к скорости работы функций, ни к практике их использования (Ну где это видано, что по сотне раз подряд присваивается одно и тоже значение переменной? Хороший компиллер в режиме оптимизации должен просто оставиль одно присваивание, а остальные - похерить! ).

Для аккуратного замера скорости работы функции нужно:
1. "Убить" все лишние процессы в системе;
2. Мерять время выполнения функции точно (в тактах, как я показывал выше);
3. Иметь большой массив данных (заведомо бОльший, чем размер кешей на машине и содержащий станиц, заведомо больше, чем число входов таблицы TLB - Translation lookaside buffer). Этот массив заполнять данными перед каждым вызовом таймируемой функции, чтобы "вытолкнуть" из кешей и TLB все используемые функцией данные и адреса.
4. Перед каждым вызовом таймируемой функции вызывать функцию с исполняемым кодом, заведомо бОльшим, чем размер кеша кода, чтобы "вытолкнуть" из него код таймируемой функции.

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

Для сравнения реализаций функций (что в обсуждаемом случае имеет место), нужно всё-же делать "ручную оптимизацию" в полном объёме (с инкрементами и их анализом), а не усеченный вариант, как у Serguei Kolossov и, подозреваю, - у Вас. Что бы сравнивать сравнимые вещи.

И последнее: MKL ориентирована на использование Интеловких процессоров и Интеловских компиляторов. Нужно аккуратно пользоваться опциями оптимизации, чтобы MKL показала всё, на что способна.

43. Serguei Kolossov, 20.02.2002 13:02
Возобновляю дисскуссию по теме.
По поводу корректности MKL процедур.
Есть функции:
1) ddoti из Sparce BLAS
2) собственной конструкции.
Вроде как своя правильно работает, а вот результаты различны с MKL-евской версией.
Вывод: или я чего-то непонимаю, или в MKL ddoti не то чтобы ошибка, а так - несостыковка C++ и FORTRAN.

Вот код :

double my_ddoti(int &n,double *x,int *ind,double *y)
{
double res=0;
for (int j=0;j<n;j++) res=res+x[j]*y[ind[j]];
return res;
}
void main ()
{ int i,n=5;
double d=0.0;
double * x;x=new double[n];for (i=0;i<n;i++) x[i]=pow(10,i);
int * id;id=new int[n];for (i=0;i<n;i++) id[i]=i;
double * y;y=new double[n];for (i=0;i<n;i++) y[i]=1;

d=0;
d=my_ddoti(n,x,id,y);
cout<<"Result of home:"<<d<<endl;

d=cblas_ddoti(n,x,id,y);
cout<<"Result of intel:"<<d<<endl;
}

Но результаты следующие:
Result of home:11111
Result of intel:11110
Test is finished.

Я понимаю, что вектор X не совсем sparce но это дела не меняет. Я так сделал, чтобы проще ошибку искать было.

Очень бы хотелось узнать мнения товарищей

quest

и


IronPeter

Ну и всех, кому интересно, тоже.
Спасибо.

Добавление от 20-02-2002 13:05:

Chudik
Почему тема отмечена как :"(перенесена Korzh из форума "Системные платы")" ?
Она там никогда небыла.



URL: http://forum.ixbt.com/topic.cgi?id=8:13630

Время GMT +03. Даты в формате dd.mm.yyyy.