Вот вот , они очень не плохо 32 битный оптимизировали.

тем не менее произошло это недавно ) до этого 32-бит никакой был вообще. грел на уровне прайма или чуть больше и производительность в среднем отставала на 25-30% относительно 64-х битки. Теперь в районе 10% макс.

комрады подскажите,может ли это говорить о нестабильности камня в разгоне:
а именно иногда после начала теста первая(бывает и вторая) строка отличается от нужного значения...далее же все пучком и все значения как положено совпадают и с минусом...гигафлопсы тоже чего-то не особо большие

aus Какая-то легкая ошибка.. не первый раз такое попадается. Но обычно там где такая ситуация, то то БСОДы то черный экран..

aus
Что за мать? Есть матки, которые в простое выдают меньшую напругу, чем в нагрузке. Возможно это тот случай. Слегка подними напругу на проц

да вроде ненаблюдалось такого...
Timo92 мамка профильная...напруга задрана уже прилично как для такого разгона...1,384 в простое с просадкой в тесте 1,372
а по поводу гигафлопсов что сказать можно???как по мне то как-то очень они уж малекие

Если это девятая версия линпака то норм , а если десятая , то мало.

ха! вот это прикол! вот резалт но соль не в этом


а в том что частоту он не правильно определяет! он её сам вычисляет помножив множитель проца на частоту шины! и получил 3.5! а множитель-то 9 я поставил! т.е. 3150 на самом деле) а по производительности получилось быстрее даже чем на 3.5 реальных .. очень интересно

Как можно расценивать следующую ошибку (совсем плохо или ничего страшного):


Intel(R) LINPACK data

Current date/time: Thu Jun 26 21:50:46 2008

CPU frequency: 3.392 GHz
Number of CPUs: 2
Number of threads: 2
Parameters are set to:

Number of tests : 1
Number of equations to solve (problem size) : 16130
Leading dimension of array : 16130
Number of trials to run : 200
Data alignment value (in Kbytes) : 4

Maximum memory requested that can be used = 2081741896, at the size = 16130
============= Timing linear equation system solver =================

Size LDA Align. Time(s) GFlops Residual Residual(norm)
16130 16130 4 142.944 19.5761 2.539880e-010 3.459913e-002
16130 16130 4 137.520 20.3482 2.539880e-010 3.459913e-002
...
...
...
16130 16130 4 137.504 20.3506 2.539880e-010 3.459913e-002
16130 16130 4 137.467 20.3561 2.539880e-010 3.459913e-002
16130 16130 4 137.501 20.3511 2.484800e-010 3.384881e-002 - вот ошибка на 196 проходе теста
16130 16130 4 137.498 20.3515 2.539880e-010 3.459913e-002
16130 16130 4 137.532 20.3464 2.539880e-010 3.459913e-002
16130 16130 4 137.485 20.3534 2.539880e-010 3.459913e-002
16130 16130 4 137.495 20.3519 2.539880e-010 3.459913e-002

Performance Summary (GFlops)

Size LDA Align. Average Maximal
16130 16130 4 20.3468 20.3564

End of tests
27.06.2008
06:00

telemeh
нестабильность. но судя по отклонению значения - "очень маленькая".
плохо когда сильно колбасит и числа оч. сильно отличаются.

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

telemeh Это ерунда.

Quwant
В смысле?
Можно не предавать особого значения?

telemeh Именно.

Intel(R) LINPACK data

Current date/time: Sun Jun 29 03:02:07 2008

CPU frequency: 3.330 GHz
Number of CPUs: 2
Number of threads: 2
Parameters are set to:

Number of tests : 1
Number of equations to solve (problem size) : 13700
Leading dimension of array : 13700
Number of trials to run : 10
Data alignment value (in Kbytes) : 4

Maximum memory requested that can be used = 1501798096, at the size = 13700
============= Timing linear equation system solver =================

Size LDA Align. Time(s) GFlops Residual Residual(norm)
13700 13700 4 99.535 17.2262 1.816194e-010 3.425883e-002
13700 13700 4 99.784 17.1832 1.816194e-010 3.425883e-002
13700 13700 4 98.972 17.3243 1.816194e-010 3.425883e-002
13700 13700 4 98.858 17.3442 1.816194e-010 3.425883e-002
13700 13700 4 101.192 16.9441 1.816194e-010 3.425883e-002
13700 13700 4 97.945 17.5058 1.816194e-010 3.425883e-002
13700 13700 4 97.959 17.5033 1.816194e-010 3.425883e-002
13700 13700 4 97.952 17.5046 1.816194e-010 3.425883e-002
13700 13700 4 97.957 17.5037 1.816194e-010 3.425883e-002
13700 13700 4 97.968 17.5018 1.816194e-010 3.425883e-002

Performance Summary (GFlops)

Size LDA Align. Average Maximal
13700 13700 4 17.3541 17.5058
скажите пожалуйста, раз значение Residual(norm) постоянно 3.425883e-002 значит стабильно? и правильно я подобрал условия тестирования на стабильность (не считая количество прогонов)? зарание спасибо

Это говорят обычно о теоретических цифрах. А вот реальная производительность измеряется тем же линпаком, только компилируется под Brook+ или C graph
http://www.gpgpu.org/
Япошки полгода назад сделали кластер на 8800GTX, на linux.org.ru новость была.

Intel(R) LINPACK data

Current date/time: Thu Jul 03 09:50:21 2008

CPU frequency: 3.600 GHz
Number of CPUs: 4
Number of threads: 4
Parameters are set to:

Number of tests : 1
Number of equations to solve (problem size) : 29640
Leading dimension of array : 29640
Number of trials to run : 100
Data alignment value (in Kbytes) : 4

Maximum memory requested that can be used = 2733866400, at the size = 29640
============= Timing linear equation system solver =================

Size LDA Align. Time(s) GFlops Residual Residual(norm)
29640 29640 4 372.922 46.5554 7.448862e-010 3.014471e-002
29640 29640 4 363.511 47.7606 7.448862e-010 3.014471e-002
29640 29640 4 363.326 47.7849 7.448862e-010 3.014471e-002
29640 29640 4 362.036 47.9551 7.448862e-010 3.014471e-002
29640 29640 4 362.210 47.9322 7.448862e-010 3.014471e-002
29640 29640 4 362.294 47.9210 7.448862e-010 3.014471e-002
29640 29640 4 362.488 47.8954 7.448862e-010 3.014471e-002
29640 29640 4 362.729 47.8635 7.448862e-010 3.014471e-002
29640 29640 4 362.454 47.8998 7.448862e-010 3.014471e-002
29640 29640 4 362.529 47.8900 7.448862e-010 3.014471e-002
29640 29640 4 362.663 47.8723 7.448862e-010 3.014471e-002
29640 29640 4 362.530 47.8898 7.448862e-010 3.014471e-002
29640 29640 4 362.485 47.8957 7.448862e-010 3.014471e-002
29640 29640 4 362.471 47.8977 7.448862e-010 3.014471e-002
29640 29640 4 363.184 47.8036 7.448862e-010 3.014471e-002
29640 29640 4 358.525 48.4248 7.448862e-010 3.014471e-002
29640 29640 4 358.098 48.4826 7.448862e-010 3.014471e-002
29640 29640 4 358.377 48.4448 7.448862e-010 3.014471e-002
29640 29640 4 357.845 48.5169 7.448862e-010 3.014471e-002
29640 29640 4 362.304 47.9197 7.448862e-010 3.014471e-002
29640 29640 4 361.820 47.9838 7.448862e-010 3.014471e-002
29640 29640 4 361.189 48.0677 7.448862e-010 3.014471e-002
29640 29640 4 361.180 48.0688 7.448862e-010 3.014471e-002
29640 29640 4 375.877 46.1893 7.448862e-010 3.014471e-002
29640 29640 4 368.895 47.0635 7.448862e-010 3.014471e-002
29640 29640 4 375.792 46.1997 7.448862e-010 3.014471e-002
29640 29640 4 367.860 47.1960 7.448862e-010 3.014471e-002

вот Винда Виста Ультимейт х64, проц заменен на Q9450 раньше был Q6600, пиковая температура по ядрам 75 средняя 70
Напруга по биосу 1,35 по CPU-Z - 1.336 (не проседает) вообщем процом очень доволен !

и еще что характерно у Q9450 ядра прогреваются равномерно +/- 1 гр а в ку6600 разница достигала иногда 15 гр между ядрами в томже линпаке !

после того как включил кондиционер температура упала где-то на 3-5 гр

заблуждаешся! с появлением стандарта PCI-E 2.0 а в последствии 3.0 скорости взаимодействия видеоадаптера и памяти на столько сократятся что сама по себе видео память и её объем не будут иметь столь большого значения т.к. видеокарте не составит труда и без особых потерь обмениваться информацией с ОЗУ на материнской плате

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

Вот например цитата из тобой приведённой статьи:

и как правильно уже подмечал banifatich конечная производительность сильно зависит от используемых алгоритмов, и не важно в чём выводится результат в попугаях или гигафлопсах

А на процессорах не зависит от приложения? Речь идет о такой простой задаче как например решение огромной системы линейных уравнений. Думаю, тот же Линпак на CUDA будет летать.
Другое дело, что скоро.. выйдет Larraby и это будет конец.. того компьютерного "ангажемента" к которому мы привыкли. Наступит новая эра. Помните, ходили слухи о том, что G80 это скрытый х86-вычислитель?
Скорее всего, новый пост-ларраби чип от нВ будет х86-совместимым

у кого что! у кого система линейных уравнений, у кого что-то с молекулами, смысл в том что и то и то через разные алгоритмы можно решать и конечная скорость зависит от их совершенства. Это на бумаге "всё просто" выглядит, а запрограммировать можно разными способами и решать тоже и один будет быстрее другой медленнее в зависимости от совершенства технической части. И конечно зависит от сложности самих уравнений...... Я как бы об этом говорил

Core 2 Duo E6550 3500MHz 1,45V